[Bug testsuite/33082] [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors)

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2007-08-16 07:12 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00982.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||08/msg00982.html
  Component|tree-optimization   |testsuite


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

[Bug libstdc++/33084] New: Small typo in valarray header

[willkomm at sc dot rwth-aachen dot de]

There appears to be a simple typo in header valarray. 
Loction is Line 1012 in file 
libstdc++-v3/include/std/valarray 
in the current svn trunc
in the third of three operators defined by the macro
_DEFINE_BINARY_OPERATOR

I think this line should be changed from

return _Expr<_Closure, _Tp>(_Closure(__t, __v));\

to

return _Expr<_Closure, _Rt>(_Closure(__t, __v));\

similar to the corresponding lines in the two former 
operator definitions of that macro.

A test program which does not compile currently, but does compile after the
suggested change would be

#include 

std::valarray res(10);
std::valarray vc(10);
char c;

int main() {
  res = c == vc;
}

This mistake is also in gcc 4.1 and 4.2. I hope this helps.

Regards
Johannes Willkomm


-- 
   Summary: Small typo in valarray header
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: willkomm at sc dot rwth-aachen dot de
 GCC build triplet: any
  GCC host triplet: any
GCC target triplet: any


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

[Bug c++/31132] [4.1/4.2/4.3 regression] ICE on inconsistent friend declaration

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2007-08-16 09:05 ---
Subject: Bug 31132

Author: paolo
Date: Thu Aug 16 09:05:17 2007
New Revision: 127535

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127535
Log:
/cp
2007-08-16  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/31132
* pt.c (tsubst_friend_function): When check_classfn
returns error_mark_node likewise return it.

/testsuite
2007-08-16  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/31132
* g++.dg/template/crash69.C: New.

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


-- 


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

[Bug c++/31132] [4.1/4.2 regression] ICE on inconsistent friend declaration

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2007-08-16 09:08 ---
Fixing the problem on 4_1-branch and 4_2-branch depends on fixing 27211...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

  BugsThisDependsOn||27211
 AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE on
   |on inconsistent friend  |inconsistent friend
   |declaration |declaration


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

[Bug libstdc++/33084] Small typo in valarray header

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-08-16 09:41 ---
Thanks. This isn't a regression, I'm going to apply your patch to mainline and
4_2-branch only.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-16 09:41:25
   date||


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

[Bug c++/33012] ICE on throwing copy of object returned by reference from method with traits-deduced return-type

[raymond at corvil dot com]

--- Comment #3 from raymond at corvil dot com  2007-08-16 09:50 ---
Yes, it does not happen with recent releases.  I logged it because I couldn't
find any hint of this problem having been seen and noted anywhere.  I just
wanted to let you know about it in case the problem has simply been masked by
recent code changes rather than specifically fixed (not that I'm suggesting it
has ;-) I just don't know).  Thanks!


-- 


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

[Bug middle-end/32897] Invalid rematerialisation of subregs

[rsandifo at gcc dot gnu dot org]

--- Comment #1 from rsandifo at gcc dot gnu dot org  2007-08-16 10:16 
---
Subject: Bug 32897

Author: rsandifo
Date: Thu Aug 16 10:16:15 2007
New Revision: 127536

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127536
Log:
gcc/
PR middle-end/32897
* reload.c (find_reloads): Check that the memory returned by
find_reloads_toplev was not the result of forcing a constant
to memory.
(find_reloads_toplev): Always use simplify_gen_subreg to get
the subreg of a constant.  If the result is also a constant,
but not a legitimate one, force it into the constant pool
and reload its address.

gcc/testsuite/
* gcc.dg/torture/pr32897.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr32897.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/179] gcc -O2 -Wuninitialized missing warning with &var under 2.95.x and 3.x

[manu at gcc dot gnu dot org]

--- Comment #10 from manu at gcc dot gnu dot org  2007-08-16 10:19 ---
Some analysis http://gcc.gnu.org/ml/gcc/2007-08/msg00271.html


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dnovillo at google dot com
   Last reconfirmed|2004-03-04 02:59:01 |2007-08-16 10:19:12
   date||


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

[Bug middle-end/32897] Invalid rematerialisation of subregs

[rsandifo at gcc dot gnu dot org]

--- Comment #2 from rsandifo at gcc dot gnu dot org  2007-08-16 10:21 
---
Patch applied.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libgcj/33085] New: liblt_prog_compiler_pic_GCJ='-DDLL_EXPORT' is wrong

[dannysmith at users dot sourceforge dot net]

Bug reported by Ross Ridge to mingw users list 

When building libgcj for windows targets, libtool puts -DDLL_EXPORT in compiler
flag:

mingw* | cygwin* | pw32* | os2*)
  # This hack is so that the source file can tell whether it is being
  # built for inclusion in a dll (and should export symbols for example).
  # Although the cygwin gcc ignores -fPIC, still need this for old-style
  # (--disable-auto-import) libraries
  lt_prog_compiler_pic='-DDLL_EXPORT'
  ;;


However that -D is a preprocessor flag (not a proper compiler switch)  gcj
gives -D a different meaning:

from jvspec.c:lang_specific_driver

  if (saw_D && ! main_class_name)
fatal ("can't specify '-D' without '--main'\n");

As a result, libtool build of shared  libgcj  fails with:

bin/bash ./libtool --tag=GCJ --mode=compile /src/gcc/obj/gcc/gcj
-B/src/gcc/obj/mingw32/libjava/ -B/src/gcc/obj/gcc/ -ffloat-store
-fomit-frame-pointer -Usun -fno-omit-frame-pointer -fclasspath=
-fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -c -o java/lang/Object.lo
-fsource-filename=../../../gcc/libjava/java/lang/Object.java
../../../gcc/libjava/classpath/lib/java/lang/Object.class
libtool: compile: /src/gcc/obj/gcc/gcj -B/src/gcc/obj/mingw32/libjava/
-B/src/gcc/obj/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-fno-omit-frame-pointer -fclasspath=
-fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=../../../gcc/libjava/java/lang/Object.java
../../../gcc/libjava/classpath/lib/java/lang/Object.class -DDLL_EXPORT -o
java/lang/.libs/Object.o
gcj.exe: can't specify '-D' without '--main'


-- 
   Summary: liblt_prog_compiler_pic_GCJ='-DDLL_EXPORT'  is wrong
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net


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

[Bug c/33083] noreturn function should be invoked via JMP

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-16 10:38 ---


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


-- 

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

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-08-16 10:38 ---
*** Bug 33083 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||us15 at os dot inf dot tu-
   ||dresden dot de


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

[Bug middle-end/33086] New: warn for read-only uninitialized variables passed as arguments

[manu at gcc dot gnu dot org]

void use(const int *);

void foo(void)
{
  int i;
  use(&i);
}

At least for languages where 'const' is actually enforced, we should warn for
this. For languages where the 'const' can be cast away and 'i' can be
initialized by 'use' the situation is less clear (although personally I think
we should warn anyway). This is one part of PR10138.

"the question whether an argument is actually used or not is secondary, the
fact that we pass an uninitialized variable to which only read access is
possible 
is definitely worth a warning."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138#c8


-- 
   Summary: warn for read-only uninitialized variables passed as
arguments
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manu at gcc dot gnu dot org
OtherBugsDependingO 10138
 nThis:


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

[Bug other/33087] New: Add dependency information to object files and make use of it

[raselmsh at hotmail dot com]

It would be very nice if GCC could save the dependency information for an
object file in the file itself (ideally including the checksums of the source
files used to build it) and optionally check this information when compiling,
so that it would skip files which are up-to-date.  I think that this would have
the potential to seriously reduce makefile-hell and build times.  A usage
example:

cd $(OBJECT_OUTPUT_DIRECTORY)
gcc -c $(GCC_OPTIONS) source_file1.c source_file2.c source_file3.c ...

Where only those object files out of source_file1.o, source_file2.o,
source_file3.o ... which were out of date would be rebuilt.  Compare this to
the number of lines currently needed to manage dependencies correctly.


-- 
   Summary: Add dependency information to object files and make use
of it
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raselmsh at hotmail dot com


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

[Bug other/33087] Add dependency information to object files and make use of it

[raselmsh at hotmail dot com]

--- Comment #1 from raselmsh at hotmail dot com  2007-08-16 10:55 ---
Not related to the bug, but is there a way of hiding e-mail addresses in this
bugzilla?  I have switched from my real address to a more or less disposable
one to get around this, but it would be nicer to be able to use my real one.


-- 


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

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2007-08-16 10:57 ---
Let's simplify this report. This one is now about 

int atoi(const char *);
int foo()
{
char buf[10];
return atoi(buf);
}

As comment #3 mentions, this is a combination of 

1) Report use of uninitialized array elements (PR27120).
2) Report pointers to uninitialized variables passed as const* arguments
(PR33086).

I guess that if we achieve both things, we will have a chance to achieve this
one. In other words, both PRs are blocking this one.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
  BugsThisDependsOn||27120
OtherBugsDependingO|27120   |
  nThis||
Summary|-Wuninitialized could catch |warn for uninitialized
   |uninitialized arrays|arrays passed as const*
   ||arguments


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

[Bug middle-end/33086] warn for read-only uninitialized variables passed as arguments

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-16 10:59 ---
> At least for languages where 'const' is actually enforced

There is none, unless you are taking about fortran "in" arguments.  So we need
to mark such argument as special.

Now if you have the full program (or at least the containts of use function),
and you can prove it never writes to the incoming pointer argument, then you
can warn but only then.

In C and C++ you can never tell without the body of use.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO|24639   |
  nThis||


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

[Bug middle-end/33086] warn for read-only uninitialized variables passed as arguments

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Priority|P3  |P5


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

[Bug other/33087] Add dependency information to object files and make use of it

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-08-16 11:02 ---
You can use ccache to get this same behavior.  You can also use -MD to get
automatic dependency checking.

>ideally including the checksums of the source files used to build it

That will not work for some stuff where headers change.  You are better off
using ccache which is actually a nice addon program that is already done to
deal with this use case really.


-- 


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

[Bug other/33087] Add dependency information to object files and make use of it

[raselmsh at hotmail dot com]

--- Comment #3 from raselmsh at hotmail dot com  2007-08-16 11:14 ---
How reliable is ccache?  I have tried it (or was it a different C Cache?), but
uninstalled after I found that it caused some compile runs to fail, presumably
after misselecting the object file from the cache.

To clarify the above - by source files, I meant any files needed to produce the
object file, like what gcc outputs if you ask it for the dependencies of a
source file now.

And this would have at least one advantage over ccache - if it were an actual
part of GCC, then it would be possible after the feature became common to
distribute makefiles making use of it.  Right now, that would mean requiring
the recipient to install ccache on their machine.


-- 


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

[Bug middle-end/33086] warn for read-only uninitialized variables passed as arguments

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2007-08-16 11:19 ---
(In reply to comment #1)
> > At least for languages where 'const' is actually enforced
> 
> There is none, 

void use(const int *a)
{
a[0] = 5;
}
void foo(void)
{
  int i;
  use(&i);
}

new.c:3: error: assignment of read-only location

Either I am misunderstanding you or your argument about overwriting the pointer
argument is equivalent to just don't using the value of 'i'. Of course, we
don't know whether the value is used or not within use() but the fact is that
'i' cannot be initialized within use().


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
   Priority|P5  |P3


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

[Bug fortran/20896] [4.2 and 4.1 only] ambiguous interface not detected

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-08-16 11:50 
---
(In reply to comment #8)
> Paul, what is the status on this one?

ping?


-- 


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[fxcoudert at gcc dot gnu dot org]

--- Comment #31 from fxcoudert at gcc dot gnu dot org  2007-08-16 12:10 
---
Marking this as FIXED, see http://gcc.gnu.org/ml/fortran/2007-08/msg00327.html
for details.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/33088] New: [4.1/4.2/4.3 Regression] spurious exceptions with -ffloat-store

[jsm28 at gcc dot gnu dot org]

Since RTH's patch ,
stores to the real or imaginary part of a complex variable are represented
using a load of the other part and a COMPLEX_EXPR.

If the variable is not yet initialized, and the load of the other part does not
get optimized away, this can yield spurious floating-point exceptions (in
particular, loading a signaling NaN on the x87 raises the "invalid" exception).
 This can happen with -ffloat-store (I don't have any proof that this is
restricted to -ffloat-store, but haven't observed the problem without this
option).

I observed the problem originally as a failure of glibc's test-double, which is
built with -ffloat-store and forms complex values by setting the real and
imaginary parts separately.  The following testcase reproduces it on
i686-pc-linux-gnu, with trunk (-ffloat-store together with any of -O1 -O2 -O3
-Os), 4.2 branch (same options), 4.1 branch (-float-store -O1), but not for 4.0
(which predates the above mentioned patch) with any of those options.  An
equivalent x86-specific test could of course be written without use of
.

#include 
#include 

volatile int x[1024];

void __attribute__((noinline))
fill_stack (void)
{
  volatile int y[1024];
  int i;
  for (i = 0; i < 1024; i++)
y[i] = 0x7ff0;
  for (i = 0; i < 1024; i++)
x[i] = y[i];
}

volatile _Complex double vc;

void __attribute__((noinline))
use_complex (_Complex double c)
{
  vc = c;
}

double t0, t1, t2, t3;

#define USE_COMPLEX(X, R, C) \
  do { __real__ X = R; __imag__ X = C; use_complex (X); } while (0)

void __attribute__((noinline))
use_stack (void)
{
  _Complex double a, b, c, d;
  USE_COMPLEX (a, t0, t1);
  USE_COMPLEX (b, t1, t2);
  USE_COMPLEX (c, t2, t3);
  USE_COMPLEX (d, t3, t0);
}

int
main (void)
{
  fill_stack ();
  feclearexcept (FE_INVALID);
  use_stack ();
  if (fetestexcept (FE_INVALID))
abort ();
  exit (0);
}


-- 
   Summary: [4.1/4.2/4.3 Regression] spurious exceptions with -
ffloat-store
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||08/msg01012.html
   Target Milestone|--- |4.3.0


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

[Bug libfortran/32989] GETARG intrinsic

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-08-16 13:28 
---
Well, the gfortran doc says "Shall be of type INTEGER(4), N >= 0". This is in
contradiction with the g77 doc, which says: "Pos: INTEGER not wider than the
default kind; scalar; INTENT(IN)."

Note that the arguments names are also in disagreement: gfortran says
  CALL GETARG(N, ARG)
while g77 has
  CALL GetArg(Pos, Value)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||documentation, rejects-valid
   Last reconfirmed|2007-08-04 22:20:49 |2007-08-16 13:28:17
   date||
Summary|getarg and -fdefault-   |GETARG intrinsic
   |integer-8   |


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

[Bug libfortran/33079] Optional empty strings do not appear to be 'PRESENT'

[patchapp at dberlin dot org]

--- Comment #4 from patchapp at dberlin dot org  2007-08-16 13:25 ---
Subject: Bug number PR33079

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01012.html


-- 


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

[Bug rtl-optimization/33089] New: combine not combining add + test in if (a + b) > 0

[rask at gcc dot gnu dot org]

Consider this simple test case:

extern void foo (void);
extern void bar (void);

void bgtutest (unsigned int a, unsigned int b)
{
  if (a + b > 0)
foo ();
  else
bar ();
}

gcc mainline revision 127532 -O2 -S -dp:

bgtutest:
.LFB2:
addl%edi, %esi  # 7 *addsi_1/1  [length = 2]
testl   %esi, %esi  # 8 *cmpsi_ccno_1/1 [length = 2]
jne .L5 # 9 *jcc_1  [length = 2]
jmp bar # 15*call_0 [length = 5]
.p2align 4,,10
.p2align 3
.L5:
jmp foo # 11*call_0 [length = 5]

The reason is that combine insists on simplifying a + b > 0 as a == -b (as seen
in the dump file):

Failed to match this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 59 [ b ])
(neg:SI (reg/v:SI 58 [ a ]

Failed to match this instruction:
(set (pc)
(if_then_else (eq (neg:SI (reg/v:SI 58 [ a ]))
(reg/v:SI 59 [ b ]))
(label_ref 13)
(pc)))


-- 
   Summary: combine not combining add + test in if (a + b) > 0
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
 GCC build triplet: x86_64-unkonwn-linux-gnu
  GCC host triplet: x86_64-unkonwn-linux-gnu
GCC target triplet: x86_64-unkonwn-linux-gnu


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

[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2007-08-16 14:35 ---
Starting program: /home/steven/devel/build-test/gcc/cc1 -g -O2 -fPIC -Dpa64=1
-mlong-calls -fkeep-inline-functions libgcc2.i
 __multc3
Analyzing compilation unit
Performing interprocedural optimizations
 
Assembling functions:
 __multc3
Breakpoint 1, fancy_abort (file=0xcdbc31 "../../trunk/gcc/gcse.c", line=3236,
function=0xcdc050 "local_cprop_pass") at ../../trunk/gcc/diagnostic.c:655
655   internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1  0x006dcd3a in local_cprop_pass (alter_jumps=1 '\001')
at ../../trunk/gcc/gcse.c:3236
3236  gcc_assert (libcall_sp == &libcall_stack[MAX_NESTED_LIBCALLS]);
(gdb) l
3231}
3232
3233  /* Forget everything at the end of a basic block.  Make sure we
are
3234 not inside a libcall, they should never cross basic blocks. 
*/
3235  cselib_clear_table ();
3236  gcc_assert (libcall_sp == &libcall_stack[MAX_NESTED_LIBCALLS]);
3237}
3238
3239  cselib_finish ();
3240
(gdb)

Definitely a problem with the nested libcalls handling.


-- 

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 |2007-08-16 14:35:32
   date||


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

[Bug c/23872] .t02.original dump weirdness

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2007-08-16 14:39 ---
I think this is confirmed. Patches welcome! 


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-08-16 14:39:58
   date||


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

[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2007-08-16 14:54 ---
Created an attachment (id=14064)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14064&action=view)
remove nested libcall handling from gcse.c

This is the *only* place in the entire compiler where GCC handles nested
libcalls. I've had this patch for a long time now, but no-one seemed to be
interested much in doing something about libcall notes.  Maybe someone wants to
finish this patch now?


-- 


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

[Bug middle-end/33086] warn for read-only uninitialized variables passed as arguments

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-08-16 14:58 ---


void use(const int *a)
{
  int *b = (int*)a;
b[0] = 5;
}
void foo(void)
{
  int i;
  use(&i);
}


-- 


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

[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2007-08-16 15:05 ---
Fix for the bug:

Index: lower-subreg.c
===
--- lower-subreg.c  (revision 127558)
+++ lower-subreg.c  (working copy)
@@ -897,7 +897,7 @@ resolve_simple_move (rtx set, rtx insn)
 static bool
 resolve_clobber (rtx pat, rtx insn)
 {
-  rtx reg;
+  rtx reg, note;
   enum machine_mode orig_mode;
   unsigned int words, i;
   int ret;
@@ -909,8 +909,11 @@ resolve_clobber (rtx pat, rtx insn)
   /* If this clobber has a REG_LIBCALL note, then it is the initial
  clobber added by emit_no_conflict_block.  We were able to
  decompose the register, so we no longer need the clobber.  */
-  if (find_reg_note (insn, REG_LIBCALL, NULL_RTX) != NULL_RTX)
+  note = find_reg_note (insn, REG_LIBCALL, NULL_RTX);
+  if (note != NULL_RTX)
 {
+  rtx retval_insn = XEXP (note, 0);
+  remove_retval_note (retval_insn);
   delete_insn (insn);
   return true;
 }


In case someone cares enough to fix this properly: GCC should probably also
remove the REG_LIBCALL_ID notes of all the insns in the libcall chain -- but we
don't do that anywhere else right now and the above patch is sufficient to
avoid the ICE.


-- 


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

[Bug fortran/33090] New: Unable to build on AIX 4.3.3

[bugzilla-gcc at thewrittenword dot com]

gfortran won't build on AIX 4.3.3 as it doesn't have weak support:
...
/opt/build/gcc-4.1.2-objdir/./gcc/xgcc -B/opt/build/gcc-4.1.2-objdir/./gcc/
-B/o
pt/TWWfsw/gcc41/powerpc-ibm-aix4.3.3.0/bin/
-B/opt/TWWfsw/gcc41/powerpc-ibm-aix4
.3.3.0/lib/ -isystem /opt/TWWfsw/gcc41/powerpc-ibm-aix4.3.3.0/include -isystem
/
opt/TWWfsw/gcc41/powerpc-ibm-aix4.3.3.0/sys-include -DHAVE_CONFIG_H -I.
-I/opt/b
uild/gcc-4.1.2/libgfortran -I. -iquote/opt/build/gcc-4.1.2/libgfortran/io
-I/opt
/build/gcc-4.1.2/libgfortran/../gcc
-I/opt/build/gcc-4.1.2/libgfortran/../gcc/co
nfig -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissi
ng-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2
-pthread
 -c /opt/build/gcc-4.1.2/libgfortran/runtime/environ.c   -DPIC -o
.libs/environ.
o
In file included from /opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-aix.h:33,
 from ../../.././gcc/gthr-default.h:1,
 from /opt/build/gcc-4.1.2/libgfortran/../gcc/gthr.h:114,
 from /opt/build/gcc-4.1.2/libgfortran/runtime/../io/io.h:36,
 from /opt/build/gcc-4.1.2/libgfortran/runtime/environ.c:37:
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:92: warning: weak
declarati
on of '__gthrw_pthread_once' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:93: warning: weak
declarati
on of '__gthrw_pthread_getspecific' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:94: warning: weak
declarati
on of '__gthrw_pthread_setspecific' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:95: warning: weak
declarati
on of '__gthrw_pthread_create' not supported
/opt/build/gcc-4.1.2/libgfortran/../gcc/gthr-posix.h:96: warning: weak
declarati
on of '__gthrw_pthread_cancel' not supported
...

I am building with --enable-threads.


-- 
   Summary: Unable to build on AIX 4.3.3
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
 GCC build triplet: powerpc-ibm-aix4.3.3.0
  GCC host triplet: powerpc-ibm-aix4.3.3.0
GCC target triplet: powerpc-ibm-aix4.3.3.0


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

[Bug libfortran/32989] GETARG intrinsic

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-08-16 15:19 ---
> Well, the gfortran doc says "Shall be of type INTEGER(4), N >= 0". This is in
> contradiction with the g77 doc, which says: "Pos: INTEGER not wider than the
> default kind; scalar; INTENT(IN)."

Well, N >= 0 vs. pos > 0 should not be a problem as N = 0 is (where supported)
the name of the invoked program; this helps also with compatibility to other
vendors such as Intel.

> Note that the arguments names are also in disagreement: gfortran says
>   CALL GETARG(N, ARG)
> while g77 has
>   CALL GetArg(Pos, Value)
g95 follows g77.

And Intel has:
CALL GETARG (n, buffer [, status])
(Error: status = -1; otherwise status = number of characters before
padding/trunkation)


-- 


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

[Bug middle-end/22456] [4.1/4.2/4.3 regression] missing "is used uninitialized" warning

[dnovillo at gcc dot gnu dot org]

--- Comment #15 from dnovillo at gcc dot gnu dot org  2007-08-16 15:22 
---

If not an exact duplicate, it's strongly related to 18501.  The code pattern is
slightly different so it may be worth keeping around.  Adding a dependency on
18501.


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||18501


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

[Bug c++/33091] New: [c++0x] ICE using remove_reference on variadic param pack

[chris dot fairles at gmail dot com]

Environment:
System: Linux coffeebuzz.miovision.corp 2.6.18-8.1.8.el5 #1 SMP Tue Jul 10
06:39:17 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64

host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ../gcc/configure CC=gcc43 CXX=g++43 --program-suffix=43
--disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20070811 (experimental)

Description:

ICE when using
"typename std::remove_reference<_UElements>::type &&... "

Compiled with:
g++43 -std=c++0x -save-temps tuple_error.cpp -o tuple_error

Compiler output:
tuple_error.cpp: In function ‘int main()’:
tuple_error.cpp:65: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

How-To-Repeat:
Compile attached code:
g++43 -std=c++0x -save-temps tuple_error.cpp -o tuple_error


-- 
   Summary: [c++0x] ICE using remove_reference on variadic param
pack
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot fairles at gmail 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=33091

[Bug c++/33091] [c++0x] ICE using remove_reference on variadic param pack

[chris dot fairles at gmail dot com]

--- Comment #1 from chris dot fairles at gmail dot com  2007-08-16 15:57 
---
Created an attachment (id=14065)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14065&action=view)
source file that produces ICE

attached source file that causes ICE


-- 


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

[Bug c++/33091] [c++0x] ICE using remove_reference on variadic param pack

[chris dot fairles at gmail dot com]

--- Comment #2 from chris dot fairles at gmail dot com  2007-08-16 15:58 
---
Created an attachment (id=14066)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14066&action=view)
-save-temps compiler output


-- 


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

[Bug c++/33091] [c++0x] ICE using remove_reference on variadic param pack

[chris dot fairles at gmail dot com]

--- Comment #3 from chris dot fairles at gmail dot com  2007-08-16 15:59 
---
Created an attachment (id=14067)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14067&action=view)
-save-temps compiler output


-- 


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

[Bug middle-end/33092] New: Using -O1 -fno-tree-salias results in ICE

[sje at cup dot hp dot com]

While turning off optimizations to try and track down a compiler bug I noticed
that if I used -fno-tree-salias with -O1 the compiler would ICE:

x.c: In function 'main':
x.c:1: internal compiler error: in verify_curr_properties, at passes.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

This can be reproduced by compiling any program with "-O1 -fno-tree-salias".


-- 
   Summary: Using -O1 -fno-tree-salias results in ICE
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com


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

[Bug c++/33025] [4.3 Regression] Wrong calling of placement new with conditionals

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-08-09 09:18:30 |2007-08-16 16:02:42
   date||


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

[Bug c++/33091] [c++0x] ICE using remove_reference on variadic param pack

[chris dot fairles at gmail dot com]

--- Comment #4 from chris dot fairles at gmail dot com  2007-08-16 16:16 
---
Adding:

template
tuple(const tuple<_UElements...>& __in, typename std::enable_if<
  std::is_same<
std::integral_constant,
std::integral_constant>::value>::type* =
0)
: _Inherited(__in) { }

(whether its legal or not) gives ICE:
prelude/tuple.hpp: In instantiation of ‘test::tuple’:
tuple_test.cpp:28:   instantiated from here
prelude/tuple.hpp:206: internal compiler error: tree check: expected tree_vec,
have type_pack_expansion in tsubst_copy_and_build, at cp/pt.c:10416

when explicitly instantiating template,
template class test::tuple;


-- 


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

[Bug middle-end/33092] [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org
Summary|Using -O1 -fno-tree-salias  |[4.3 Regrsssion] Using -O1 -
   |results in ICE  |fno-tree-salias results in
   ||ICE
   Target Milestone|--- |4.3.0


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

[Bug fortran/33072] "use mod, only: operator(.sub.)" matches any procedure "sub"

[patchapp at dberlin dot org]

--- Comment #2 from patchapp at dberlin dot org  2007-08-16 16:50 ---
Subject: Bug number PR33072

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01039.html


-- 


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

[Bug middle-end/33092] [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE

[dberlin at dberlin dot org]

--- Comment #1 from dberlin at gcc dot gnu dot org  2007-08-16 17:37 ---
Subject: Re:  [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE

Yeah, we either need to remove salias, or force create an empty
may_alias pass that returns TODO_may_alias but does nothing else.

I'm not sure which is the better option (I don't really see the point
of -fno-tree-salias, it would be like -fno-tree-call-cloberring)

On 16 Aug 2007 16:54:38 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --
>
> pinskia at gcc dot gnu dot org changed:
>
>What|Removed |Added
> 
>  CC||dberlin at gcc dot gnu dot
>||org
> Summary|Using -O1 -fno-tree-salias  |[4.3 Regrsssion] Using -O1 -
>|results in ICE  |fno-tree-salias results in
>||ICE
>Target Milestone|--- |4.3.0
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33092
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug fortran/33072] "use mod, only: operator(.sub.)" matches any procedure "sub"

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-08-16 18:17 ---
Subject: Bug 33072

Author: burnus
Date: Thu Aug 16 18:17:46 2007
New Revision: 127564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127564
Log:
2007-08-16  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33072
* module.c (gfc_match_use): Mark user operators as such.
(find_use_name_n): Distinguish between operators and other symbols.
(find_use_name,number_use_names,mio_namelist,
 load_operator_interfaces,load_generic_interfaces,read_module,
 write_generic): Update find_use_name_n calls.

2007-08-16  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/33072
* gfortran.dg/use_9.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/use_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33072] "use mod, only: operator(.sub.)" matches any procedure "sub"

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-08-16 18:20 ---
FIXED - but only the initially reported bug. The other I push back to PR31298.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/32972] performance of pack/unpack

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2007-08-16 18:16 ---
Hi Dominique,

would you be willing to give the patch at

http://gcc.gnu.org/ml/fortran/2007-08/msg00295.html

a spin on your Mac to check whether this is OK?  That would
be great, because I don't have a big-endian system, and the
breakage introduced by an earlier version was on a big-endian
machine. 


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dominiq at lps dot ens dot
   ||fr


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

[Bug testsuite/33082] [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors)

[uros at gcc dot gnu dot org]

--- Comment #4 from uros at gcc dot gnu dot org  2007-08-16 18:30 ---
Subject: Bug 33082

Author: uros
Date: Thu Aug 16 18:30:14 2007
New Revision: 127565

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127565
Log:
PR testsuite/33082
* gcc.dg/dfp/convert-dfp-fold.c: Use -O2 instead of -O in dg-options.
* gcc.dg/dfp/convert-bfp-fold.c: Ditto.
* gcc.dg/dfp/convert-int-fold.c: Ditto.
* gcc.dg/dfp/operator-arith-fold.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/dfp/convert-bfp-fold.c
trunk/gcc/testsuite/gcc.dg/dfp/convert-dfp-fold.c
trunk/gcc/testsuite/gcc.dg/dfp/convert-int-fold.c
trunk/gcc/testsuite/gcc.dg/dfp/operator-arith-fold.c


-- 


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

[Bug testsuite/33082] [4.3 Regression] Revision 127491 causes FAIL: gcc.dg/dfp/convert-bfp-fold.c (test for excess errors)

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2007-08-16 18:33 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

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


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

[Bug bootstrap/33065] warning in Comparing stages 2 and 3: cd: stage3-gcc: No such file or directory

[mbo dot massimo at tiscali dot it]

--- Comment #7 from mbo dot massimo at tiscali dot it  2007-08-16 19:27 
---
(From update of attachment 14063)
make logs generated building gcc in a directory different from source directory


-- 

mbo dot massimo at tiscali dot it changed:

   What|Removed |Added

  Attachment #14063|make log of the build   |new make log of the build
description|process |process


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

[Bug target/33011] [4.3 Regression] frv: error: bad output_move_single operand

[rask at gcc dot gnu dot org]

--- Comment #3 from rask at gcc dot gnu dot org  2007-08-16 19:49 ---
Revision 127532 works.


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/33093] New: ICE in C++ frontend with constant defined in template specialization

[ian at airs dot com]

When I compile this test case with gcc 4.1, 4.2, or mainline, I get an ICE:

foo.cc: In instantiation of ‘const unsigned char B::c’:
foo.cc:20:   instantiated from ‘const unsigned char C >::c’
foo.cc:26:   instantiated from here
foo.cc:20: internal compiler error: in instantiate_decl, at cp/pt.c:14162

As far as I can see this is valid C++ code.

template class A
{
public:
  typedef T T1;
};

template class B
{
public:
  static const T c;
};

template
const unsigned char B::c = 1;

template class C
{
public:
  typedef typename T::T1 T2;
  static const T2 c = B::c;
};

unsigned char
fn ()
{
  return C >::c;
}


-- 
   Summary: ICE in C++ frontend with constant defined in template
specialization
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug c++/33093] ICE in C++ frontend with constant defined in template specialization

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-16 21:01 ---
>As far as I can see this is valid C++ code.
It is not but the way to fix it is doing:
template<>
const unsigned char B::c = 1;

- cut --
This is a dup of bug 24791

*** 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=33093

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

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2007-08-16 21:01 
---
*** Bug 33093 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ian at airs dot com


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

[Bug c++/31751] [4.1/4.2 regression] ICE with forgotten member declaration

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2007-08-16 22:42 
---
Hi Paolo,

this was apparently fixed by your patch for PR27211 (and not PR33035).
A backport would be nice to fix the regression here.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pcarlini at suse dot de
  BugsThisDependsOn||27211


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

[Bug fortran/33090] Unable to build on AIX 4.3.3

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-08-17 00:32 ---
Huh?  The warnings should be ok.  What exact error are you getting because I
don'
t see -Werror on the command line so the warnings should not be stoping the
build?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/33075] (mingw) Dwarf2-EH causes stack leak with VLA

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-08-17 00:36 ---
>I think this may be related to the deallocation problem reported in PR 19771

It is unrelated as the BIND_EXPR is there for this testcase and so is the
builtin to dealloc the memory.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/30013] Multiple flaws in decimal floating-point arithmetic conversions fixed

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2007-08-17 00:40 ---
Ben just mentioned this PR to me, I hadn't seen it before.

I'm working on a patch to support TFmode for powerpc*-linux, and I'll talk to
HJ about proper support for XFmode.  Initially we didn't support long double
because  we were testing on powerpc64-linux where there was no C library
support for 128-bit long double.  Now that there is, we can support it.

Thanks for the test, I'll modify it so it doesn't violate aliasing rules and
add it to the testsuite.  Please report other problems you find.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org
 AssignedTo|bje at gcc dot gnu dot org  |janis at gcc dot gnu dot org


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

[Bug c++/33094] New: ICE on valid C++ virtual template static member in namespace

[ian at airs dot com]

This C++ code gets an ICE with gcc 4.2 and with mainline.  I believe this is
valid C++ code.

namespace
{

template 
class A
{
  virtual T f1() { return c; }
  static const T c = 0;
};

A v;

}

foo.cc: In instantiation of ‘const int ::A::c’:
foo.cc:7:   instantiated from ‘T::A::f1() [with T = int]’
foo.cc:11:   instantiated from here
foo.cc:8: internal compiler error: in make_rtl_for_nonlocal_decl, at
cp/decl.c:4967
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 
   Summary: ICE on valid C++ virtual template static member in
namespace
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

Jeremie added you as a friend

[Jeremie]

Jeremie sent you a friend request on MySpace.

Click this link to join and Jeremie will be added as your friend:

http://www1.myspace.com/reloc.cfm?c=2&id=A8516BAB-FB7B-4C88-9CFA-C0ABB2253419


Thanks,

your friends at MySpace







-

This email was sent by someone who knows you on MySpace.com.

If you want to block any emails from MySpace members in the future, you can 
click here:

http://www1.myspace.com/misc/block.cfm?iid=A8516BAB-FB7B-4C88-9CFA-C0ABB2253419

Or send a single blank email with the subject line "BLOCK" to:

[EMAIL PROTECTED]

You can also block future email or direct any other inquiries by regular postal 
mail to:

MySpace, Inc.
8391 Beverly Blvd. #349
Los Angeles, CA 90048
USA

©2003-2007 MySpace.com. All Rights Reserved.

[Bug middle-end/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter

[bje at gcc dot gnu dot org]

--- Comment #8 from bje at gcc dot gnu dot org  2007-08-17 05:24 ---
Subject: Bug 32970

Author: bje
Date: Fri Aug 17 05:24:24 2007
New Revision: 127578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127578
Log:
PR middle-end/32970
gcc/
* tree.c (reconstruct_complex_type): For a pointer to a vector,
use build_qualified_type to retain qualifiers of the base type.
testsuite/
* g++.dg/ext/altivec-14.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/altivec-14.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c


-- 


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

[Bug fortran/33095] New: MAX with optional arguments gives run-time error

[burnus at gcc dot gnu dot org]

This is a fallout from PR31198.

Using
   a = MAX(1,2, a1, a2)
where a1 and a2 are optional arguments: If both a1 and a2 are not present,
gfortran gives a bogus run-time error message:

Fortran runtime error: Second argument of 'max' intrinsic should be present

Looking at the dump, gfortran optimized the second argument away:

  MAX(2,a1,a2)

if a1 is now not present ...

Fortran 2003:
13.7.71 MAX (A1, A2 [, A3, ...])
13.7.76 MIN (A1, A2 [, A3, ...])
Fortran 95:
13.14.64 MAX (A1, A2 [, A3, ...])
13.14.69 MIN (A1, A2 [, A3, ...])
See also:
http://groups.google.com/group/comp.lang.fortran/msg/be6db97903228689

Test case (from c.l.f):

  PROGRAM testoptarg
PRINT *, m1(3,4)
PRINT *, m1(3)
PRINT *, m1() ! gives the run-time error
  CONTAINS
INTEGER FUNCTION m1(a1,a2)
  INTEGER, OPTIONAL, INTENT(IN) :: a1,a2
  m1 = max(1, 2, a1, a2)
END FUNCTION m1
  END PROGRAM testoptarg


-- 
   Summary: MAX with optional arguments gives run-time error
   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: burnus at gcc dot gnu dot org


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

[Bug middle-end/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter

[bje at gcc dot gnu dot org]

--- Comment #9 from bje at gcc dot gnu dot org  2007-08-17 06:49 ---
Fixed in r127578.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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