[Bug c++/34774] [4.1/4.2 Regression] templates, enumerations, overflow, ice

[tbptbp at gmail dot com]

--- Comment #21 from tbptbp at gmail dot com  2008-02-14 07:52 ---
I've already submitted PR34864 for the folding but apparently i've overdone the
reduction; it's actually slightly tricky to trigger the issue (i mean i've
obviously hit another problem in that PR).

Right now i'm out of inspiration as to how to can convey my point :) 


-- 


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

[Bug c++/35192] Base method overloading hides base public method in derived class.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-14 07:50 ---
This is what the C++ standard says.
overloading g will hide all of g functions in the base class.  if you want not
to have them hidden you have to add an using statement.
Like:

class Derived : public Base {
public:
  using Base::g;
 protected:
  virtual void g(int i, int j) {}
};


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35192] New: Base method overloading hides base public method in derived class.

[gaysinsky at google dot com]

Code example:

class Base {
 public:
  void g(int i) {}

 protected:
  virtual void g(int i, int j) {}
};


class Derived : public Base {
 protected:
  virtual void g(int i, int j) {}
};


int main() {
  Derived o;
  o.g(5);
  return 0;
}

Compilation output:
dos/quotas/test.cc: In function 'int main()':
dos/quotas/test.cc:18: error: no matching function for call to
'Derived::g(int)'
dos/quotas/test.cc:12: note: candidates are: virtual void Derived::g(int, int)


-- 
   Summary: Base method overloading hides base public method in
derived class.
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gaysinsky at google dot com


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

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

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2008-02-14 06:59 
---
It's true that having the new target not work well is embarrassing, but it's
not a regression of any kind.  However, if we don't fix this, then we certainly
shouldn't brag about support for this target in the NEWS for the new release. 
So, I've marked this P1 -- but we can get it down to P4 by checking that we're
not claiming support for this target, if we can't fix the defect.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug middle-end/35149] [4.3 Regression] ICE: in expand_call_inline, at tree-inline.c:2653

[Ralf dot Wildenhues at gmx dot de]

--- Comment #8 from Ralf dot Wildenhues at gmx dot de  2008-02-14 06:46 
---
Subject: Re:  [4.3 Regression] ICE: in
expand_call_inline, at tree-inline.c:2653

* hubicka at gcc dot gnu dot org wrote on Wed, Feb 13, 2008 at 06:29:51PM CET:
> --- Comment #7 from hubicka at gcc dot gnu dot org  2008-02-13 17:29 
> ---
> This one liner actually took me a while.  It is quite ugly ordering issue.
> Index: ipa.c
> ===
> --- ipa.c   (revision 132243)
> +++ ipa.c   (working copy)
> @@ -192,6 +192,7 @@ cgraph_remove_unreachable_nodes (bool be
> }
>   cgraph_node_remove_callees (node);
>   node->analyzed = false;
> + node->local.inlinable = false;
> }
>   else
> cgraph_remove_node (node);

This patch fixes the failure for me.  Thanks for working on it!


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

--- Comment #26 from ubizjak at gmail dot com  2008-02-14 06:45 ---
(In reply to comment #25)
> > (Could someone with darwin bootstraps and regtest removal of these defines? 
> > Do
> > we even have an example of a failure for latest 4.3 if these are not 
> > defined?)
> 
> I bootstraped without the defines and I have a bus error on two tests in my
> list, the simplest is:

This one also fails for i686-linux-gnu, plain -O2.

(gdb) run
Starting program: /home/uros/test/a.out 
   8   5  12

Program received signal SIGSEGV, Segmentation fault.
extract_int (p=0x8, len=4) at ../../../gcc-svn/trunk/libgfortran/io/write.c:151


-- 


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

[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-02-14 06:07 
---
Patch in comment #6 has a regression.


-- 


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

[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-02-14 06:00 
---
Created an attachment (id=15147)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15147&action=view)
Tentative patch

This patch fixes the test case when writing to an actual file, but not to
stdio.  Stdout is not seekable so this won't work for that case.  We will have
to do some more work on how we handle buffering of pre-connected units to do
better than this, and I don't think its worth the effort.  (Tabbing in formats
is a heck of a way to seek.  :)  Regression testing this now.


-- 


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

[Bug rtl-optimization/35190] New: Wrong branch instruction with -freorder-blocks-and-partition on SH

[kkojima at gcc dot gnu dot org]

On SH, gcc.dg/tree-prof/bb-reorg.c test fails with assembler
messages like:

/tmp/cc3RtxMk.s: 115: Error: displacement to defined symbol .L27 overflows
12-bit field

It happens with a branch from .text to .text.unlikely section
where the label .L27 is placed on.
I've found that bb-reorder makes crossing unconditional branches
into indirect jumps when the architecture doesn't have unconditional
branches that can span all of memory.  This is the case for SH and
the rtls for the above branch in .bbpart rtl dump look like:

(insn 172 156 173 10 (set (reg:SI 211)
(label_ref:SI 155)) -1 (insn_list:REG_LABEL_OPERAND 155 (nil)))

(jump_insn 173 172 159 10 (set (pc)
(reg:SI 211)) -1 (expr_list:REG_CROSSING_JUMP (nil)
(nil)))

which will be assembled to the correct jmup instruction across
sections on this target.
It seems that local-alloc.c:update_equiv_regs replaces this
indirect jump back into a usual jump.  The corresponding part
of .lreg dump is

(jump_insn:HI 173 156 159 13 (set (pc)
(label_ref:SI 155)) 219 {jump_compact} (expr_list:REG_CROSSING_JUMP
(nil)
(nil)))

which is assembled to a bad short branch instruction on SH.
I'm testing the patch below, though SH has a separate issue with
constant pools for bb-reorg.c test.

--- ORIG/trunk/gcc/local-alloc.c2008-01-17 09:41:36.0 +0900
+++ TMP/trunk/gcc/local-alloc.c 2008-02-14 11:14:04.0 +0900
@@ -1107,7 +1107,8 @@ update_equiv_regs (void)

  /* Don't substitute into a non-local goto, this confuses CFG.  */
  if (JUMP_P (insn)
- && find_reg_note (insn, REG_NON_LOCAL_GOTO, NULL_RTX))
+ && (find_reg_note (insn, REG_NON_LOCAL_GOTO, NULL_RTX)
+ || find_reg_note (insn, REG_CROSSING_JUMP, NULL_RTX)))
continue;

  for (link = REG_NOTES (insn); link; link = XEXP (link, 1))


-- 
   Summary: Wrong branch instruction with -freorder-blocks-and-
partition on SH
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh4-unknown-linux-gnu


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

[Bug c/30949] "incompatible pointer type" warning does not point to declaration

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-14 02:15 ---
I have a patch for this but it is not suitable for stage3, so it'll have to
wait until 4.4.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |manu at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-14 02:15:51
   date||


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

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

[nightstrike at gmail dot com]

--- Comment #3 from nightstrike at gmail dot com  2008-02-14 01:53 ---
Can we have this fixed before 4.3.0?  x86_64-pc-mingw32 is a new target for
this release, and it shouldn't be delivered completely broken.  


-- 


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-02-14 01:44 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00483.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[dannysmith at users dot sourceforge dot net]

--- Comment #4 from dannysmith at users dot sourceforge dot net  2008-02-14 
01:43 ---
Actually, I see this as unfortunate choice of name for the undocumented
__alloca label rather than as a serious bug. 

__alloca is an internal symbol that should have been named _alloca_probe for
consistency with MSVCT.

Certainly it is not a regression.  It has been that way since 1996.  The mingw
header malloc.h  does this to get a MSVCRT-consistent alloca:
#ifdef __GNUC__
#define _alloca(x) __builtin_alloca((x))
#endif 


-- 


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

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-14 01:20 ---
(In reply to comment #2)
> This bug needs to be finished off before 4.3.0 closes...

Why?  it has been a bug in GCC for a while now.  And x86_64-pc-mingw32 is new.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[nightstrike at gmail dot com]

--- Comment #2 from nightstrike at gmail dot com  2008-02-14 01:17 ---
This bug needs to be finished off before 4.3.0 closes...


-- 


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

[Bug c++/28743] [4.1/4.2/4.3 regression] ICE with invalid specialization

[andreasmeier80 at gmx dot de]

--- Comment #7 from andreasmeier80 at gmx dot de  2008-02-14 00:35 ---
The patch is approved at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00392.html


-- 

andreasmeier80 at gmx dot de changed:

   What|Removed |Added

 CC||andreasmeier80 at gmx dot de


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[michael dot meissner at amd dot com]

--- Comment #4 from michael dot meissner at amd dot com  2008-02-14 00:20 
---
In terms of shipping systems, no AMD system supports SSSE3 right now.  As I
understand it, the SSSE3 instructions were inbetween SSE3 and SSE4.1 on Intel
systems, so -mno-sse3 should turn off SSSE3, but -mno-sse4a should not turn off
SSSE3.  Current shipping AMD systems do support SSE3.


-- 


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

[Bug target/34393] ICE: in extract_insn, at recog.c:1990

[amodra at bigpond dot net dot au]

--- Comment #8 from amodra at bigpond dot net dot au  2008-02-14 00:18 
---
fix applied


-- 

amodra at bigpond dot net dot au changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/34393] ICE: in extract_insn, at recog.c:1990

[amodra at gcc dot gnu dot org]

--- Comment #7 from amodra at gcc dot gnu dot org  2008-02-14 00:17 ---
Subject: Bug 34393

Author: amodra
Date: Thu Feb 14 00:17:11 2008
New Revision: 132309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132309
Log:
PR target/34393
* config/rs6000/rs6000.md (restore_stack_block): Force operands[1]
to a reg.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.md


-- 


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

[Bug target/34393] ICE: in extract_insn, at recog.c:1990

[amodra at gcc dot gnu dot org]

--- Comment #6 from amodra at gcc dot gnu dot org  2008-02-14 00:17 ---
Subject: Bug 34393

Author: amodra
Date: Thu Feb 14 00:16:29 2008
New Revision: 132306

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132306
Log:
PR target/34393
* config/rs6000/rs6000.md (restore_stack_block): Force operands[1]
to a reg.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/rs6000/rs6000.md


-- 


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

[Bug target/34393] ICE: in extract_insn, at recog.c:1990

[amodra at gcc dot gnu dot org]

--- Comment #5 from amodra at gcc dot gnu dot org  2008-02-14 00:15 ---
Subject: Bug 34393

Author: amodra
Date: Thu Feb 14 00:14:45 2008
New Revision: 132304

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132304
Log:
PR target/34393
* config/rs6000/rs6000.md (restore_stack_block): Force operands[1]
to a reg.


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


-- 


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-02-14 00:11 ---
-mno-sse4.1 and -mno-sse4.2 shouldn't turn off SSE4A.
-mno-sse3/-mno-sse2/-mno-sse should turn off SSE4A. But
I am not sure about -mno-ssse3.


-- 


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[michael dot meissner at amd dot com]

--- Comment #2 from michael dot meissner at amd dot com  2008-02-13 23:55 
---
Umm, SSE4A is completely different from SSE4/SSE4.1/SSE4.2.  SSE4A are the
instructions added with AMD's Barcelona machine, while SSE4.1 is the
instructions added with the current generation of Intel machines (Penryn if
memory serves), and SSE4.2 will be the instructions in the next Intel release. 
The whole naming scheme is unfortunate, especially SSSE3 and SSE4A. 


-- 


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

[Bug target/35189] -mno-sse4.2 turns off SSE4a

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-13 23:49 ---
#define OPTION_MASK_ISA_SSE4_2_UNSET OPTION_MASK_ISA_SSE4A


I don't see this as a bug, if the AMD processors don't have 4.2, they will
never have 4a.


-- 

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=35189

[Bug target/35189] New: -mno-sse4.2 turns off SSE4a

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] tmp]$ cat y.c
#include 

int
main ()
{
#ifdef __SSE__
  printf ("SSE\n");
#endif
#ifdef __SSE2__
  printf ("SSE2\n");
#endif
#ifdef __SSE3__
  printf ("SSE3\n");
#endif
#ifdef __SSSE3__
  printf ("SSSE3\n");
#endif
#ifdef __SSE4_1__
  printf ("SSE4.1\n");
#endif
#ifdef __SSE4_2__
  printf ("SSE4.2\n");
#endif
#ifdef __SSE4A__
  printf ("SSE4A\n");
#endif
}
[EMAIL PROTECTED] tmp]$ /usr/gcc-4.3/bin/gcc -march=core2 -mno-sse4.2 y.c && 
./a.out
SSE
SSE2
SSE3
SSSE3
[EMAIL PROTECTED] tmp]$ /usr/gcc-4.3/bin/gcc -march=amdfam10 -mno-sse4.2 y.c &&
./a.out 
SSE
SSE2
SSE3
[EMAIL PROTECTED] tmp]$ /usr/gcc-4.3/bin/gcc -march=amdfam10 y.c && ./a.out
SSE
SSE2
SSE3
SSE4A
[EMAIL PROTECTED] tmp]$


-- 
   Summary: -mno-sse4.2 turns off SSE4a
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

--- Comment #25 from dominiq at lps dot ens dot fr  2008-02-13 23:41 ---
> (Could someone with darwin bootstraps and regtest removal of these defines? Do
> we even have an example of a failure for latest 4.3 if these are not defined?)

I bootstraped without the defines and I have a bus error on two tests in my
list, the simplest is:

!module CHECK_SEM

! Submitted by Walt Brainerd, The Fortran Company
! GNU Fortran 95 (GCC 4.1.0 20050322 (experimental))
! Windows XP

! Produces "a.exe has encountered a problem" window.

! Same problem if comments are removed so that
!the function is in a module.

!  contains

function CHECK_INTEGER4_RANK1 (EXPECTED)
!  integer(4), dimension(:), intent(in) ::  EXPECTED
  integer(4), dimension(1:) ::  EXPECTED
  logical  :: CHECK_INTEGER4_RANK1
  print *, EXPECTED
  CHECK_INTEGER4_RANK1 = all(EXPECTED == 0)
end function CHECK_INTEGER4_RANK1

!end module CHECK_SEM

program array_test
!use CHECK_SEM
integer(4), dimension(3) ::  dat
logical :: CHECK_INTEGER4_RANK1, res

!  print *, CHECK_INTEGER4_RANK1 ((/8,5,12/))
  dat = (/8,5,12/)
  print *, dat
  res = CHECK_INTEGER4_RANK1 (dat)
  print *,  res

end program array_test

These tests passed with my previous build, so the regression is probably due to
the defines removal, though I cannot rule out that it has been introduced by
recent changes (not in gfortran). I have launched a full regtesting, but the
results will be available tomorrow morning.


-- 


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

[Bug debug/35065] [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations

[matz at gcc dot gnu dot org]

--- Comment #14 from matz at gcc dot gnu dot org  2008-02-13 23:03 ---
Sigh.  I've tested the changed testcase only on 32bit :-(  Update to r132300.


-- 


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

[Bug c++/35138] [4.3 Regression] g++ rejects valid code

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-02-13 22:32 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/35138] [4.3 Regression] g++ rejects valid code

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2008-02-13 22:31 ---
Subject: Bug 35138

Author: jakub
Date: Wed Feb 13 22:30:43 2008
New Revision: 132298

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132298
Log:
PR c++/35138
* parser.c (cp_parser_pseudo_destructor_name): If next tokens
are not identifier :: ~, return before calling cp_parser_type_name.

* g++.dg/template/member8.C: New test.

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


-- 


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

[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[lennox at cs dot columbia dot edu]

--- Comment #15 from lennox at cs dot columbia dot edu  2008-02-13 22:27 
---
Arguably, the use of static data (possible excepting const static data) or a
non-inline static function is worthy of a pedwarn.  But I'd certainly be
inclined to agree for static inline functions.


-- 


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

[Bug inline-asm/35160] [4.3 regression] local-alloc introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-02-13 22:25 ---
Can you please submit it (or even commit as obvious)?
Sorry for not thinking about this asm needing 6 regs on i?86, where it is
sometimes too much.


-- 


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

[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[ebotcazou at gcc dot gnu dot org]

--- Comment #17 from ebotcazou at gcc dot gnu dot org  2008-02-13 22:25 
---
> It is too optimistic about addressability.

It takes the address of non-addressable things:

  base &VIEW_CONVERT_EXPR((system__aux_dec__TsaB) a_3(D))


-- 


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

[Bug debug/35065] [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-02-13 22:24 ---
This is not sufficient.
block_New, nal_get_annexeb, block_ChainGather still don't have prototypes and
thus:
warning: cast to pointer from integer of different size
is reported on each of the casts of these function calls to (block_t *).


-- 


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

[Bug c++/35158] g++ does not compile valid C++ for loops with -fopenmp

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-13 22:10 ---
Confirmed in GCC 4.3 revision 132291.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-13 22:10:56
   date||


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

[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2008-02-13 22:04 ---
I also can't reproduce it (neither on native nor with a cross).

Any local patches?  Maybe you can reduce it to a set of simpler configuration
options?  


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug middle-end/35136] [4.3 Regression] ICE caused by address calculation with loop variable when optimization is on

[ebotcazou at gcc dot gnu dot org]

--- Comment #16 from ebotcazou at gcc dot gnu dot org  2008-02-13 21:54 
---
> So, what exactly is wrong now?

Oh nothing, just the generated code. :-)

  D.375_38 = (system__aux_dec__TsaB) a_3(D);
  A.36 = D.375_38;
  A.37_35 = (system__address *) &A.36;
  ivtmp.34_32 = (unsigned int) A.37_35;

[...]

  D.379_8 = (system__aux_dec__TsaB) a_3(D);
  A.38 = D.379_8;
  D.380_1 = &A.38 + 2;
  D.381_97 = (unsigned int) D.380_1;
  if (ivtmp.34_58 == D.381_97)

We compare apples (address of A.36) with orange (address of A.38).

> And what is this IVOPTs problem? ;)

It is too optimistic about addressability.


-- 


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

[Bug driver/34904] -march=native doesn't work with multiple input files

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-02-13 21:44 ---
(In reply to comment #4)
> This is confirmed. H.J., are you waiting for something to commit to 4.2 or
> should this be closed?
> 

I requested it for 4.2:

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00471.html


-- 


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

[Bug middle-end/35188] Missing a warning: if-condition is inherently blocking the if-body

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-02-13 21:43 ---
Try 4.3.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Version|unknown |4.1.3


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

[Bug middle-end/35188] Missing a warning: if-condition is inherently blocking the if-body

[tuttle at sandbox dot cz]

--- Comment #2 from tuttle at sandbox dot cz  2008-02-13 21:41 ---
(In reply to comment #1)
> -Wunreachable-code should warn already.
> -- Pinski

I've tried -Wunreachable-code before submitting this enhancement request.

gcc 4.1.3 in Ubuntu GG does not warn.


-- 


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

[Bug c++/35187] Incorrect scope resolution for inherited template member.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-13 21:39 ---
This is by the C++ standard design.

See http://gcc.gnu.org/gcc-3.4/changes.html and [temp.dep]/3 in the C++
standard.


-- 

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=35187

[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load

[joel at gcc dot gnu dot org]

--- Comment #11 from joel at gcc dot gnu dot org  2008-02-13 21:38 ---
This failed on psim for me.  AFAIK it doesn't have Altivec.  Sorry,


-- 


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

[Bug middle-end/35188] Missing a warning: if-condition is inherently blocking the if-body

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-13 21:37 ---
-Wunreachable-code should warn already.

-- Pinski


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|debug   |middle-end


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

[Bug target/34930] [4.3 Regression] ICE in instantiate_virtual_regs_in_insn with vector splat load

[matz at gcc dot gnu dot org]

--- Comment #10 from matz at gcc dot gnu dot org  2008-02-13 21:28 ---
Created an attachment (id=15145)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15145&action=view)
patch

Give this patch a test.  The problem is that rs6000.c accepts all offsets
in addresses when they are based on virtual-stack-reg (as here), at least
before reload.  The change from virtual-stack-reg to a different pseudo
leaves an offsetted address, but one that isn't acceptable anymore, as
V4SImode only accepts reg+reg or reg.  That's why the predicate doesn't match
the operand in the check of instantiate_virtual_regs, but the fallback code
simply forces it into a register in that case.  That of course only works
when the predicate accepts a register, which it doesn't in this case.

The solution is simple: if we have a MEM, whose address got changed, and now
isn't acceptable anymore, load the address into a REG instead of the whole
MEM.  If that still isn't acceptable the original check will also happen again
and reload the whole operand, so it's conservatively correct.

The testcase compiles, but I think I have no altivec capable machine readily
available to regstrap the patch.  Someone do that for me please :)


-- 


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

[Bug c++/34962] [4.1/4.2/4.3 regression] ICE with VLA and attribute in template

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-02-13 21:28 ---
Subject: Bug 34962

Author: jason
Date: Wed Feb 13 21:27:16 2008
New Revision: 132297

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132297
Log:
PR c++/34962, c++/34937, c++/34939
* decl2.c (is_late_template_attribute): Always defer attributes
vector_size and weak.

Added:
trunk/gcc/testsuite/g++.dg/ext/tmplattr9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c


-- 


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

[Bug debug/35188] New: Missing a warning: if-condition is inherently blocking the if-body

[tuttle at sandbox dot cz]

I would consider to be great when this code

if ( (var == 1) && (var == 2) ) { body }

would cause a warning, that the body is
unreachable under any circumstances.

I have made several mistakes like this in the
past and it is annoying to track down...


-- 
   Summary: Missing a warning: if-condition is inherently blocking
the if-body
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tuttle at sandbox dot cz


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

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

[manu at gcc dot gnu dot org]

--- Comment #7 from manu at gcc dot gnu dot org  2008-02-13 21:08 ---
Is this still a problem in a recent GCC ?


-- 

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=17755

[Bug driver/34904] -march=native doesn't work with multiple input files

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2008-02-13 21:05 ---
This is confirmed. H.J., are you waiting for something to commit to 4.2 or
should this be closed?


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-13 21:05:32
   date||


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

[Bug c++/35187] New: Incorrect scope resolution for inherited template member.

[john_millaway at ghrsystems dot com]

The compiler is unable to find inherited template member data from within the
derived class's method. In the sample code,  B inherits from A, but within a
method of B, the compiler can not resolve A's member data.

$ /opt/gcc-4.2.2/bin/g++ -v --save-temps dim.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.2/configure --disable-nls --prefix=/opt/gcc-4.2.2
Thread model: posix
gcc version 4.2.2
 /opt/gcc-4.2.2/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -E -quiet -v
-D_GNU_SOURCE dim.cpp -mtune=generic -fpch-preprocess -o dim.ii
ignoring nonexistent directory
"/opt/gcc-4.2.2/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gcc-4.2.2/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2

/opt/gcc-4.2.2/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/i686-pc-linux-gnu

/opt/gcc-4.2.2/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/backward
 /usr/local/include
 /opt/gcc-4.2.2/include
 /opt/gcc-4.2.2/lib/gcc/i686-pc-linux-gnu/4.2.2/include
 /usr/include
End of search list.
 /opt/gcc-4.2.2/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus -fpreprocessed
dim.ii -quiet -dumpbase dim.cpp -mtune=generic -auxbase dim -version -o dim.s
GNU C++ version 4.2.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64516
Compiler executable checksum: c0ecf79946fb161889ae27aec5e0ef1f
dim.cpp: In member function 'T B::m()':
dim.cpp:8: error: 'x' was not declared in this scope

$ cat dim.cpp
template 
struct A {
T x;
};

template 
struct B : A {
T  m() { return x; }
};

$ cat dim.ii
# 1 "dim.cpp"
# 1 ""
# 1 ""
# 1 "dim.cpp"
template 
struct A {
T x;
};

template 
struct B : A {
T m() { return x; }
};


-- 
   Summary: Incorrect scope resolution for inherited template
member.
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john_millaway at ghrsystems dot com


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

[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[mrs at apple dot com]

--- Comment #14 from mrs at apple dot com  2008-02-13 20:49 ---
I think we should do this; further, I think we should add && pedantic to it as
well.  Only people that want to be hurt by the standard should be.


-- 


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

[Bug rtl-optimization/31549] Documentation for -frtl-abstract-sequences is in the wrong place

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2008-02-13 20:34 ---
patch at: 


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de
   Last reconfirmed|2007-04-15 06:49:14 |2008-02-13 20:34:33
   date||


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

[Bug other/35148] make pdf has missing file in 4.3-20080208

[rwild at gcc dot gnu dot org]

--- Comment #12 from rwild at gcc dot gnu dot org  2008-02-13 20:27 ---
Fixed.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/35148] make pdf has missing file in 4.3-20080208

[rwild at gcc dot gnu dot org]

--- Comment #11 from rwild at gcc dot gnu dot org  2008-02-13 20:26 ---
Subject: Bug 35148

Author: rwild
Date: Wed Feb 13 20:25:47 2008
New Revision: 132296

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132296
Log:
PR other/35148
* Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of
srcdir.

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/Makefile.in


-- 


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

[Bug fortran/35184] ICE in gfc_conv_array_index_offset

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-02-13 20:25 ---
Confirmed.

Seems to be related to ELEMENTAL and IN probalby not having a proper array
descriptor. If my_sub is written as:

  SUBROUTINE my_sub (in, out)
TYPE(bar), DIMENSION(42, 42) :: in, out
out(1, 1:42) = in(1, 1:42)! ELEMENTAL SUBROUTINE ASSIGN_BAR
  END SUBROUTINE

no ICE occurs. Same if the subroutine ASSIGN_BAR is called directly using the
pointers from the original example, i.e.:

  SUBROUTINE my_sub (in, out)
TYPE(bar), DIMENSION(:,:), POINTER :: in
TYPE(bar), DIMENSION(:,:), POINTER :: out
ALLOCATE(out(1:42, 1:42))
CALL assign_bar(out(1, 1:42), in(1, 1:42))
  END SUBROUTINE

The latter probably doesn't make use of the ELEMENTALness of ASSIGN_BAR.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-13 20:25:10
   date||
Summary| ICE in |ICE in
   |gfc_conv_array_index_offset |gfc_conv_array_index_offset


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

[Bug ada/35186] Implicit assumptions about alignment of DImode

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2008-02-13 19:50 
---
I'll look into this once 4.3.0 is released.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-13 19:40:12 |2008-02-13 19:50:25
   date||


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

[Bug ada/35186] Implicit assumptions about alignment of DImode

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2008-02-13 19:40 
---
Thanks for opening the PR  However:

> DImode is aligned at 4 byte according to i386 psABI.

Of course the psABI doesn't say anything about DImode, only about long long.

DImode is an internal concept of the GCC compiler.

> But Ada doesn't follow i386 psABI.

Ada doesn't have to abide by the psABI, except when it interfaces C.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|i686-pc-linux-gnu   |ix86-*-*
   Last reconfirmed|-00-00 00:00:00 |2008-02-13 19:40:12
   date||
Summary|Ada doesn't follow i386 |Implicit assumptions about
   |psABI   |alignment of DImode


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

[Bug ada/35186] Ada doesn't follow i386 psABI

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-02-13 19:37 ---
Ada should either define its own alignment, independent of psABI, or it
should just follow psABI for alignment.


-- 


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

[Bug ada/35186] Ada doesn't follow i386 psABI

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-02-13 19:35 ---
maybe_pad_type has

  if (align == TYPE_ALIGN (type))
align = 0;

  if (align == 0 && !size)
return type;
...
   record = make_node (RECORD_TYPE);

That is Ada expects 8 byte alignment for DImode. But TYPE_ALIGN (type),
which conforms to psABI, is 4 byte for DImode.


-- 


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

[Bug c++/34939] [4.1/4.2/4.3 regression] ICE with friend and attribute weak

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-23 10:58:52 |2008-02-13 19:31:48
   date||


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

[Bug c++/34774] [4.1/4.2 Regression] templates, enumerations, overflow, ice

[jason at gcc dot gnu dot org]

--- Comment #20 from jason at gcc dot gnu dot org  2008-02-13 19:30 ---
Please submit a separate bug report for the folding issue, with a reduced
testcase if possible.

Incidentally, the "no integral type can represent" issue is due to one of the
enumerators being -31, and one being (unsigned long long)-31, which is a very
large positive number.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug other/35148] make pdf has missing file in 4.3-20080208

[rwild at gcc dot gnu dot org]

--- Comment #10 from rwild at gcc dot gnu dot org  2008-02-13 19:28 ---
Subject: Bug 35148

Author: rwild
Date: Wed Feb 13 19:27:34 2008
New Revision: 132295

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132295
Log:
PR other/35148
* Makefile.in (gcc-vers.texi): Use abs_srcdir for the value of
srcdir.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in


-- 


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

[Bug ada/35186] Ada doesn't follow i386 psABI

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-13 19:22 ---
psABI is only for C last time I remembered.


-- 


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

[Bug ada/35186] New: Ada doesn't follow i386 psABI

[hjl dot tools at gmail dot com]

DImode is aligned at 4 byte according to i386 psABI. This 4.4 patch

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00184.html

will use 4byte alignment for DImode. But Ada doesn't follow i386 psABI.
validate_alignment in ada/decl.c does

new_align = UI_To_Int (alignment);
...
align = MAX (align, new_align == 0 ? 1 : new_align * BITS_PER_UNIT);

It changes DImode alignment from 32bit to 64bit and turns DImode integer
into a DImode record. As the result, Ada fails to compile s-pack33.adb:

s-pack33.adb:52:49: size for "E0" too small, minimum allowed is 64
s-pack33.adb:53:49: size for "E1" too small, minimum allowed is 64
s-pack33.adb:54:49: size for "E2" too small, minimum allowed is 64
s-pack33.adb:55:49: size for "E3" too small, minimum allowed is 64
s-pack33.adb:56:49: size for "E4" too small, minimum allowed is 64
s-pack33.adb:57:49: size for "E5" too small, minimum allowed is 64
s-pack33.adb:58:49: size for "E6" too small, minimum allowed is 64
s-pack33.adb:59:49: size for "E7" too small, minimum allowed is 64
s-pack33.adb:62:30: size for "Cluster" too small, minimum allowed is 512

because validate_size has

(gdb) call debug_tree (size)
  constant
invariant 33>
(gdb) call debug_tree (type_size)
  constant
invariant visited 64>
(gdb) call debug_tree (gnu_type)
 
constant invariant visited 64>
unit size 
constant invariant visited 8>
align 64 symtab -1210166256 alias set -1 canonical type 0xb7d0ed00
fields 
sizes-gimplified asm_written visited unsigned type_2 DI size
 unit size 
align 32 symtab -1210166464 alias set -1 canonical type 0xb7d0ec98
precision 64 min  max >
unsigned decl_3 decl_5 DI file s-pack33.ads line 6 col 9 size
 unit size 
align 32 offset_align 128
offset 
bit offset  context
> Ada size 
chain >
(gdb) 

Before my patch, validate_size has

(gdb) call debug_tree (size)
  constant
invariant 33>
(gdb) 
  constant
invariant 33>
(gdb) call debug_tree (type_size)
  constant
invariant 33>
(gdb) call debug_tree (gnu_type)
 
unit size 
align 64 symtab -1208441944 alias set -1 canonical type 0xb7ca0c30
precision 64 min  max 
modulus >
sizes-gimplified visited unsigned type_2 DI size  unit size 
align 64 symtab -1208442048 alias set -1 canonical type 0xb7ca0c98
precision 64 min  max 
RM size  constant invariant 33>>
(gdb)


-- 
   Summary: Ada doesn't follow i386 psABI
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/21377] Error detected at a-stmaco.ads:65:4

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-02-13 19:10 ---
Grrr.. need to get over sinus headache.  Misread Bugzilla.  Nothing happened to
this PR.  I haven't retried sh for Ada to even know.


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug target/21377] Error detected at a-stmaco.ads:65:4

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-02-13 19:06 ---
Missed changing state on previous change.  Closed.


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/35176] SIGXFSZ in filebuf

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-02-13 19:06 ---
One issue is we have two standards here.  The POSIX one and the C++ one.  Now
getrlimit/SIGXFSZ signal is a POSIX issue while using filebuf is a C++ one. 
Now does POSIX talk about filebuf ?


-- 


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

[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #19 from joel at gcc dot gnu dot org  2008-02-13 19:05 ---
Patch applied to SVN trunk as revision 132294.

Thanks for approving it Arnaud.


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #18 from joel at gcc dot gnu dot org  2008-02-13 19:05 ---
Subject: Bug 35143

Author: joel
Date: Wed Feb 13 19:04:53 2008
New Revision: 132294

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132294
Log:
2008-02-11  Joel Sherrill <[EMAIL PROTECTED]>

PR ada/35143
* env.c: Add __rtems__ to if defined.
* s-osinte-rtems.adb: Add To_Target_Priority.  Fix formatting.
* s-osinte-rtems.ads: Add To_Target_Priority prototype and
PTHREAD_SCOPE_PROCESS/PTHREAD_SCOPE_SYSTEM constants.  Add
pragma Convention as required.
* gsocket.h: Make compile in and out of RTS.
* Makefile.in: Add system-rtems.ads.  Build DEC extensions.
Use g-soccon-rtems.ads.
* g-soccon-rtems.ads, system-rtems.ads: New files.


Added:
trunk/gcc/ada/g-soccon-rtems.ads
trunk/gcc/ada/system-rtems.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/Makefile.in
trunk/gcc/ada/env.c
trunk/gcc/ada/gsocket.h
trunk/gcc/ada/s-osinte-rtems.adb
trunk/gcc/ada/s-osinte-rtems.ads


-- 


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

[Bug c++/34774] [4.1/4.2 Regression] templates, enumerations, overflow, ice

[jason at gcc dot gnu dot org]

--- Comment #19 from jason at gcc dot gnu dot org  2008-02-13 18:44 ---
Subject: Bug 34774

Author: jason
Date: Wed Feb 13 18:43:34 2008
New Revision: 132292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132292
Log:
PR c++/34774
* pt.c (value_dependent_expression_p): Look into DECL_INITIAL
of enumerators, too.

Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/pt.c


-- 


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

[Bug c++/34937] [4.1/4.2/4.3 regression] ICE with attribute weak

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-23 10:56:18 |2008-02-13 18:43:56
   date||


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

[Bug libgomp/35185] ICE using openmp with g++-4.2

[edgurgel at gmail dot com]

--- Comment #4 from edgurgel at gmail dot com  2008-02-13 18:33 ---
G++ gives

raycaster.cpp: In member function ‘void Raycaster::cast() const’:
raycaster.cpp:43: erro interno de compilação: in create_tmp_var, at
gimplify.c:487
Por favor, envie um relato completo de erro,
com o código pré-processado se possível.
Veja http://gcc.gnu.org/bugs.html> para instruções.
For Debian GNU/Linux specific bug reporting instructions,
see .
make: ** [raycaster.o] Erro 1

trying to compile raycaster.cpp with g++-4.2 -c -O3 -pipe -mmmx -m3dnow -msse2
-msse  -fopenmp -save-temps raycaster.cpp -o raycaster.o

on ubuntu 7.10


-- 


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

[Bug libgomp/35185] ICE using openmp with g++-4.2

[edgurgel at gmail dot com]

--- Comment #3 from edgurgel at gmail dot com  2008-02-13 18:31 ---
Created an attachment (id=15144)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15144&action=view)
.i


-- 


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

[Bug libgomp/35185] ICE using openmp with g++-4.2

[edgurgel at gmail dot com]

--- Comment #2 from edgurgel at gmail dot com  2008-02-13 18:30 ---
Created an attachment (id=15143)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15143&action=view)
header


-- 


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

[Bug libgomp/35185] ICE using openmp with g++-4.2

[edgurgel at gmail dot com]

--- Comment #1 from edgurgel at gmail dot com  2008-02-13 18:30 ---
Created an attachment (id=15142)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15142&action=view)
source


-- 


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

[Bug libgomp/35185] New: ICE using openmp with g++-4.2

[edgurgel at gmail dot com]

System: Ubuntu 7.10
gcc version: 4.2.0

Problem: Using openmp extension

erro interno de compilação: in create_tmp_var, at gimplify.c:487


-- 
   Summary: ICE using openmp with g++-4.2
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edgurgel at gmail dot com


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

[Bug c++/34962] [4.1/4.2/4.3 regression] ICE with VLA and attribute in template

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-25 09:56:32 |2008-02-13 18:19:05
   date||


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

[Bug c++/28879] [4.0/4.1/4.2/4.3 regression] ICE with VLA in template function

[mark at codesourcery dot com]

--- Comment #8 from mark at codesourcery dot com  2008-02-13 18:18 ---
Subject: Re:  [4.0/4.1/4.2/4.3 regression] ICE with VLA in
 template function

jason at gcc dot gnu dot org wrote:

> Either value_dependent_expression_p needs to handle arbitrary VLA bounds, or 
> we
> need to avoid calling it if the array bound is not a constant-expression.

Exactly so.  My intent when writing v_d_e_p was that it only be called 
with constant-expressions.  (The whole idea of value-dependent 
expressions in the standard is predicated on them being 
constant-expressions; the goal is to partition constant-expressions 
which whose value is known before template substitution from those whose 
values is not known until later.)

So, I suggest that we take the second approach.


-- 


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

[Bug libstdc++/35176] SIGXFSZ in filebuf

[sebor at roguewave dot com]

--- Comment #7 from sebor at roguewave dot com  2008-02-13 18:15 ---
I see I should have checked the actual stdio behavior instead of relying on
the standard. Recent Linux and Solaris both do, in fact, generate SIGXFSZ out
of C stdio. AIX 5.3 does not, and neither does HP-UX 11.23, although HP-UX
11.33 does, suggesting a bug fix.

Do you happen to have a pointer to the text in the POSIX (or C) spec that
requires (or allows) this behavior of stdio?

Also, even if it is allowed, I still don't think it's desirable. I'm curious
what other libstdc++ maintainers think. Benjamin, Paolo? I'll probably raise
this on [EMAIL PROTECTED]


-- 


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

[Bug tree-optimization/33763] [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[hubicka at gcc dot gnu dot org]

--- Comment #11 from hubicka at gcc dot gnu dot org  2008-02-13 18:15 
---
I must say that I don't see it that safe: we can't clone the functions because
at the time fronend decide to rewrite the body by new one we are not having
functions gimplified yet.  (well we can clone, but we want to get rid of
non-gimple inlining code too). Keeping the unclonned body around seems
difficult in combination with one declaration rule.  But perhaps it is just my
limited knowledge of C and C++ frontends here..


-- 


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

[Bug c++/28879] [4.0/4.1/4.2/4.3 regression] ICE with VLA in template function

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2008-02-13 18:14 ---
The problem is that value_dependent_expression_p expects to only be called with
constant-expression arguments, but a VLA leads to calling it with a
non-constant expression argument, and we abort when we notice a cast to a
non-arithmetic type, which must not appear in a constant-expression.

Either value_dependent_expression_p needs to handle arbitrary VLA bounds, or we
need to avoid calling it if the array bound is not a constant-expression.


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

--- Comment #24 from ubizjak at gmail dot com  2008-02-13 18:11 ---
(In reply to comment #23)
> Why is it STACK_BOUNDARY on PowerPC to 128 (for both AIX and Darwin) and why
> does it work that way and x86 does not work that way?

Don't know rs6000 to tell, but it looks to me that for i686 target, gcc _tries_
to push 128bit constants to the stack due to STACK_BOUNDARY redefinition.

Please look at Comment #2, -mno-accumulate-outgoing-args (aka -Os) asm dump.
Everything would be perfectly aligned _if_ both push insn would increase SP for
128 bit.


-- 


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

[Bug fortran/35184] New: ICE in gfc_conv_array_index_offset

[beckmann dot maik at googlemail dot com]

The following code triggers an ICE with gcc-4.3-20080208

MODULE foo

  TYPE, PUBLIC :: bar
PRIVATE
  REAL :: value
  END TYPE bar

  INTERFACE ASSIGNMENT (=)
MODULE PROCEDURE assign_bar
  END INTERFACE ASSIGNMENT (=)

CONTAINS

  ELEMENTAL SUBROUTINE assign_bar (to, from)
TYPE(bar), INTENT(OUT) :: to
TYPE(bar), INTENT(IN) :: from
to%value= from%value
  END SUBROUTINE

  SUBROUTINE my_sub (in, out)
IMPLICIT NONE
TYPE(bar), DIMENSION(:,:), POINTER :: in
TYPE(bar), DIMENSION(:,:), POINTER :: out

ALLOCATE( out(1:42, 1:42) )
out(1, 1:42) = in(1, 1:42)

  END SUBROUTINE

END MODULE foo


/home/maik/workspace/gcc/gcc-4.3-20080208/stage/bin/gfortran-4.3  -o
CMakeFiles/mylib.dir/foo.f90.o  -I/home/maik/workspace/Debug_maik/Debug   -c
/home/maik/workspace/Debug_maik/foo.f90
/home/maik/workspace/Debug_maik/foo.f90: In function 'my_sub':
/home/maik/workspace/Debug_maik/foo.f90:25: internal compiler error: in
gfc_conv_array_index_offset, at fortran/trans-array.c:2201
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [CMakeFiles/mylib.dir/foo.f90.o] Error 1
make[2]: Leaving directory `/home/maik/workspace/Debug_maik/Debug'
make[1]: *** [CMakeFiles/mylib.dir/all] Error 2
make[1]: Leaving directory `/home/maik/workspace/Debug_maik/Debug'
make: *** [all] Error 2


If ELEMENTAL is omitted or replaced by PURE it compiles fine.

 -- Maik


-- 
   Summary:  ICE in gfc_conv_array_index_offset
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: beckmann dot maik at googlemail dot com


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

[Bug c++/35183] ice for legal code

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-02-13 17:59 ---
Created an attachment (id=15141)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15141&action=view)
gzipped C++ source code


-- 


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

[Bug c++/35183] New: ice for legal code

[dcb314 at hotmail dot com]

I just tried to compile Suse Linux package dasher-4.7.0-4
with the GNU C++ compiler version 4.3 snapshot 20080208

The compiler said

Alphabet/AlphIO.cpp: In member function 'void
Dasher::CAlphIO::CreateDefault()':
Alphabet/AlphIO.cpp:361: error: void value not ignored as it ought to be
Alphabet/AlphIO.cpp:361: internal compiler error: tree check: expected class
'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Source code attached. Flag -c required.


-- 
   Summary: ice for legal code
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/35182] New: ICE in coalesce_abnormal_edges

[gcc at david dot osborn dot name]

The following testcase produces an ICE. I couldn't reduce it any further. Fails
with GCC 4.2.2/4.2.3 under i686-pc-linux-gnu/i686-pc-mingw32.

#include 
#include 
int main()
{
typedef std::tr1::array, 1> Array;
Array array;
for (Array::iterator iter(array.begin());;)
{
try
{
(iter++)->reset(new int);
}
catch (...) {}
}
}

g++ -O test.cpp
test.cpp: In function 'int main()':
test.cpp:3: internal compiler error: in coalesce_abnormal_edges, at
tree-outof-ssa.c:643


-- 
   Summary: ICE in coalesce_abnormal_edges
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name


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

[Bug c++/24791] ICE on invalid instantiation of template's static member

[pinskia at gcc dot gnu dot org]

--- Comment #17 from pinskia at gcc dot gnu dot org  2008-02-13 17:33 
---
*** Bug 35181 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kltstallard at gmail dot com


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

[Bug c++/35181] internal compiler error: in import_export_decl

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-13 17:33 ---
../TNS.cpp:27: error: template arguments to
'TNSTypeDefTHelper::s_createStaticTNSTypeDefT' do not match original
template 'TNSTypeDefTHelper::s_createStaticTNSTypeDefT'
../TNS.cpp:27: note: use template<> for an explicit specialization
../TNS.cpp:28: error: template arguments to
'TNSTypeDefTHelper::s_createStaticTNSTypeDefT' do not match original
template 'TNSTypeDefTHelper::s_createStaticTNSTypeDefT'
../TNS.cpp:28: note: use template<> for an explicit specialization
../TNS.cpp:29: error: template arguments to
'TNSTypeDefTHelper::s_createStaticTNSTypeDefT' do not match original
template 'TNSTypeDefTHelper::s_createStaticTNSTypeDefT'
../TNS.cpp:29: note: use template<> for an explicit specialization
../TNS.cpp:30: error: template arguments to 'TNSTypeDefTHelper::s_createStaticTNSTypeDefT' do not match original template
'TNSTypeDefTHelper::s_createStaticTNSTypeDefT'
../TNS.cpp:30: note: use template<> for an explicit specialization
../TNS.cpp:31: error: template arguments to 'TNSTypeDefTHelper::s_createStaticTNSTypeDefT' do not match original template
'TNSTypeDefTHelper::s_createStaticTNSTypeDefT'


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


-- 

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=35181

[Bug middle-end/35149] [4.3 Regression] ICE: in expand_call_inline, at tree-inline.c:2653

[hubicka at gcc dot gnu dot org]

--- Comment #7 from hubicka at gcc dot gnu dot org  2008-02-13 17:29 ---
This one liner actually took me a while.  It is quite ugly ordering issue.
Index: ipa.c
===
--- ipa.c   (revision 132243)
+++ ipa.c   (working copy)
@@ -192,6 +192,7 @@ cgraph_remove_unreachable_nodes (bool be
}
  cgraph_node_remove_callees (node);
  node->analyzed = false;
+ node->local.inlinable = false;
}
  else
cgraph_remove_node (node);


-- 


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

[Bug c++/35181] internal compiler error: in import_export_decl

[kltstallard at gmail dot com]

--- Comment #1 from kltstallard at gmail dot com  2008-02-13 17:26 ---
Created an attachment (id=15140)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15140&action=view)
Preprocessed file that causes the error.


-- 


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

[Bug c++/35181] New: internal compiler error: in import_export_decl

[kltstallard at gmail dot com]

Note that this version of the compiler is experimental on the QNX platform.

When compiling the attached preprocessed file I get the following message:

qcc -V4.2.1,gcc_ntox86_cpp -w1 -IC:\QNX632\ARICommon
-IC:\QNX632\ARICommon\include -c -g -Wc,-Wall -oTNSTypeDef.o ..\TNSTypeDef.cpp 
..\TNS.cpp:92: internal compiler error: in import_export_decl, at
cp/decl2.c:1957
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
cc: C:/QNX632/host/win32/x86/usr/lib/gcc/i386-pc-nto-qnx6.3.0/4.2.1/cc1plus
caught signal 4
Build complete for project tnsReflection
Time consumed: 1359  ms.  Parallel threads used: 2
..\TNSTypeDef.cpp: In static member function 'static void
TNSTypeDef::sPrintMembers(TNSTypeDefStruct*)':
..\TNSTypeDef.cpp:344: warning: suggest parentheses around assignment used as
truth value


-- 
   Summary: internal compiler error: in import_export_decl
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kltstallard at gmail dot com


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

[Bug c++/34774] [4.1/4.2 Regression] templates, enumerations, overflow, ice

[tbptbp at gmail dot com]

--- Comment #18 from tbptbp at gmail dot com  2008-02-13 17:21 ---
Ah ah!
[svn pull... build...]
Sadly it makes no difference yet, most certainly because of all the kludges i
had to stuff in: out of the 2213 tests (from the ucb-corpus for +,-,*,/,sqrt)
there's still 3 of them (all additions) that g++ refuses to 'fold' completly
mov0x200627(%rip),%edx# 600c88 ::fp32>
mov0x200626(%rip),%esi# 600c90 ::fp32>
mov0x200616(%rip),%edx# 600c8c ::fp32>
So close to perfection...
And then the compile-time 'raytracer' is still fubar :)
Compilation is definitely faster, but i only have a debian 4.3 snapshot to
compare against and i suppose some checkings are enabled.

I guess i'll have to get back to it, remove all those ugly workarounds and see
if it can handle it now.

Many thanks for your efforts.

PS:
  http://ompf.org/stuff/metafloat/
  http://ompf.org/stuff/metafloat/dist/ <-- tarball here


-- 


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

[Bug c/35180] New: built-in-setjmp.x2

[joel at gcc dot gnu dot org]

Seems to be the same for most of the other built-in-setjmp tests on this
target.

Memory exception at fff4 (illegal address)

Unexpected trap (0x 9) at address 0x020013D8

data access exception at 0xFFF4


This occurs after the __builtin_longjmp() transfer control back to main().


-- 
   Summary: built-in-setjmp.x2
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: sparc-rtems4.9


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[pinskia at gcc dot gnu dot org]

--- Comment #23 from pinskia at gcc dot gnu dot org  2008-02-13 17:18 
---
Why is it STACK_BOUNDARY on PowerPC to 128 (for both AIX and Darwin) and why
does it work that way and x86 does not work that way?

-- Pinski


-- 


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

[Bug tree-optimization/21655] g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0 fails

[ghazi at gcc dot gnu dot org]

--- Comment #10 from ghazi at gcc dot gnu dot org  2008-02-13 17:05 ---
Subject: Bug 21655

Author: ghazi
Date: Wed Feb 13 17:04:46 2008
New Revision: 132289

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132289
Log:
Backport:
2005-11-30  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/21655
* g++.dg/tree-ssa/pr14814.C: Remove XFAIL.


Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/tree-ssa/pr14814.C


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[ubizjak at gmail dot com]

--- Comment #22 from ubizjak at gmail dot com  2008-02-13 17:03 ---
(In reply to comment #21)
> > Currently, it is defined as:
> >
> > #define STACK_BOUNDARY BITS_PER_WORD
> 
> In this case how can it be 4? should not it be 32 or 64?

Yes, it _is_ 32 or 64. The point is, that IT IS NOT 128, so x86_64 (that has
sse2 enabled by default) would break left and right if STACK_BOUNDARY was
required to be 128 bit.

Looking through calls.c, it is obvious that PREFERRED_STACK_BOUNDARY pretty
much guarantees 128 bit stack alignment:

--cut here--
  /* Ensure current function's preferred stack boundary is at least
 what we need.  We don't have to increase alignment for recursive
 functions.  */
  if (cfun->preferred_stack_boundary < preferred_stack_boundary
  && fndecl != current_function_decl)
cfun->preferred_stack_boundary = preferred_stack_boundary;
  if (fndecl == current_function_decl)
cfun->recursive_call_emit = true;
--cut here--

IMO, there is no need for extra paranoia in darwin.h and following defines
should be removed:

/* On Darwin, the stack is 128-bit aligned at the point of every call.
   Failure to ensure this will lead to a crash in the system libraries
   or dynamic loader.  */
#undef STACK_BOUNDARY
#define STACK_BOUNDARY 128

/* Since we'll never want a stack boundary less aligned than 128 bits
   we need the extra work here otherwise bits of gcc get very grumpy
   when we ask for lower alignment.  We could just reject values less
   than 128 bits for Darwin, but it's easier to up the alignment if
   it's below the minimum.  */
#undef PREFERRED_STACK_BOUNDARY
#define PREFERRED_STACK_BOUNDARY (ix86_preferred_stack_boundary > 128   \
  ? ix86_preferred_stack_boundary   \
  : 128)

(Could someone with darwin bootstraps and regtest removal of these defines? Do
we even have an example of a failure for latest 4.3 if these are not defined?)

AFAICS, STACK_BOUNDARY should be set to the value of "push" insn - in the sense
that x86_64 doesn't define it to (...say...) 25 or some other random value. For
sure, it should mirror PARM_BOUNDARY, otherwise various strange things happen.


-- 


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

[Bug target/35179] execs crash in shared lib destructor = do_global_dtors_aux

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|c++ |target
 GCC target triplet||i386-pc-solaris2.10


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

[Bug libstdc++/35176] SIGXFSZ in filebuf

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-02-13 16:56 ---
Calling the C stdio functions will result in the same behavior, so the as-if
rule is satisfied.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug inline-asm/35160] [4.3 regression] local-alloc introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[ubizjak at gmail dot com]

--- Comment #12 from ubizjak at gmail dot com  2008-02-13 16:42 ---
(In reply to comment #11)
> At rev. 132272 gcc.target/i386/pr35160.c fails on i686-apple-darwin9 with:

i686-apple-darwin-9 implies -fpic, so one register less is available.
This is a testsuite failure, following patch fixes it:

Index: pr35160.c
===
--- pr35160.c   (revision 132285)
+++ pr35160.c   (working copy)
@@ -1,5 +1,6 @@
 /* PR inline-asm/35160 */
 /* { dg-do run } */
+/* { dg-skip-if "" { ilp32 && { ! nonpic } } { "*" } { "" } } */
 /* { dg-options "-O2" } */


-- 


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

[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

[dominiq at lps dot ens dot fr]

--- Comment #21 from dominiq at lps dot ens dot fr  2008-02-13 16:40 ---
> Currently, it is defined as:
>
> #define STACK_BOUNDARY BITS_PER_WORD

In this case how can it be 4? should not it be 32 or 64?


-- 


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

[Bug libstdc++/35176] SIGXFSZ in filebuf

[sebor at roguewave dot com]

--- Comment #5 from sebor at roguewave dot com  2008-02-13 16:37 ---
I understand that POSIX requires the signal but I'm not sure I see what that
has to do with filebuf. C++ specifies that filebuf member functions behave
"as if" by calling the C stdio functions.

See 27.8.1, p2:

  In this subclause, the type name FILE refers to the type FILE declared in
  .
  A File provides an external source/sink stream whose underlaid character
  type is char (byte).

and 27.8.1.4, the description of filebuf::open():

  It then opens a file, if possible, whose name is the NTBS s (“as if” by
  calling std::fopen(s, modstr))

There is no mention in the C++ standard of filebuf calling POSIX write(),
and while I agree that doing so makes sense (our own implementation does
it), strictly speaking it doesn't seem to be allowed by the "as if" clause.
In addition, I don't think exposing C++ programs to signals as a result is
desirable. So it seems that a conforming implementation of filebuf that
chooses to use POSIX I/O needs to suspend signals while making POSIX calls
that might lead to signals.

If you disagree and think the C++ standard permits this behavior could you
point to the relevant wording?


-- 

sebor at roguewave dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug debug/35065] [4.3 Regression] infinite loop while compiling VLC media player in vt_find_locations

[matz at gcc dot gnu dot org]

--- Comment #12 from matz at gcc dot gnu dot org  2008-02-13 16:18 ---
Whoops, sorry.  I fixed the warnings in a different copy of the testcase
than the one I committed :-(  Committed the right version now.  (Yes, it still
tests what it should test, without the var-tracking patch it runs into an
endless loop).


-- 


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