[Bug other/35455] [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984

[bunk at stusta dot de]

--- Comment #1 from bunk at stusta dot de  2008-03-04 07:45 ---
Created an attachment (id=15258)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15258&action=view)
preprocessed source


-- 


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

[Bug other/35455] New: [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984

[bunk at stusta dot de]

$ h8300-linux-gcc -Wp,-MD,fs/.read_write.o.d  -nostdinc -isystem
/usr/local/DIR/gcc-h8300-4.3.0-RC-20080301/lib/gcc/h8300-elf/4.3.0/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -I/home/bunk/linux/kernel-2.6/git/linux-2.6/fs -Ifs
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Os -fno-stack-protector -mh
-mint32 -fno-builtin -g -D__linux__ -DUTS_SYSNAME=\"uClinux\"
-fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign 
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(read_write)" 
-D"KBUILD_MODNAME=KBUILD_STR(read_write)" -c -o fs/read_write.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/read_write.c
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/read_write.c: In function
'sys_pwrite64':
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/read_write.c:427: internal
compiler error: in compute_frame_pointer_to_fb_displacement, at
dwarf2out.c:10984
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler
error: in compute_frame_pointer_to_fb_displacement, at
dwarf2out.c:10984
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: h8300-unknown-elf


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

[Bug target/35318] [4.3/4.4 regression] ICE with inline asm in reload

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2008-03-04 07:38 
---
That's not an error-recovery issue. Reload prints the error via
  fatal_insn ("Failure trying to reload:", set);
which outputs some data and calls fancy_abort. So that's just a disguised ICE.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|error-recovery  |


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

[Bug other/35454] [4.3/4.4 Regression] m68k: internal compiler error: in find_reloads, at reload.c:3744

[bunk at stusta dot de]

--- Comment #1 from bunk at stusta dot de  2008-03-04 07:19 ---
Created an attachment (id=15257)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15257&action=view)
preprocessed source


-- 


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

[Bug other/35454] New: [4.3/4.4 Regression] m68k: internal compiler error: in find_reloads, at reload.c:3744

[bunk at stusta dot de]

This bug might be related to bug 32424 (why do you have a testsuite when
reports of ICEs when running it get completely ignored?), but I can't judge
whether it's really the same:

$ m68k-linux-gcc -Wp,-MD,fs/udf/.truncate.o.d  -nostdinc -isystem
/usr/local/DIR/gcc-m68k-4.3.0-RC-20080301/lib/gcc/m68k-linux/4.3.0/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -I/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf
-Ifs/udf -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Os -fno-stack-protector
-fno-strength-reduce -ffixed-a2 -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(truncate)"  -D"KBUILD_MODNAME=KBUILD_STR(udf)" -c
-o fs/udf/truncate.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c -save-temps
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c: In function
'udf_truncate_tail_extent':
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c:123: error: unable
to generate reloads for:
(insn:QI 59 168 60 10
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c:98 (parallel [
(set (cc0)
(compare (reg:DI 2 %d2 [54])
(reg:DI 0 %d0 [orig:56 .s_blocksize+-4 ] [56])))
(clobber (reg:DI 57))
]) 12 {*m68k.md:521} (expr_list:REG_DEAD (reg:DI 0 %d0 [orig:56
.s_blocksize+-4 ] [56])
(expr_list:REG_DEAD (reg:DI 2 %d2 [54])
(expr_list:REG_UNUSED (reg:DI 57)
(nil)
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c:123: internal
compiler error: in find_reloads, at reload.c:3744
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.3/4.4 Regression] m68k: internal compiler error: in
find_reloads, at reload.c:3744
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[hubicka at ucw dot cz]

--- Comment #16 from hubicka at ucw dot cz  2008-03-04 07:03 ---
Subject: Re:  [4.4 Regression]: FAIL: abi_check

> Note however, that the patch also didn't help Geoff's i686-linux tester, just
> have a look to gcc-testresults.

Sorry, I had two versions of patch and managed to commit the wrong copy.
Sent correct one to ML.  It should be fixed now.
> 
> 
> I think we should not mix the two issues, here. The first issue is that, IMO,
> the function we are discussing should be inlined, it's very small and we 
> always
> inlined it until recently.

The point I wanted to make is that inliner when knowing to be inlining a
cold call (because it was hinted so by __builtin_expect) is correctly a
lot more sellective.  Basically anything that expands to function call
and some extra code around is a loss for code size inlining.

Honza


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[bergner at gcc dot gnu dot org]

--- Comment #8 from bergner at gcc dot gnu dot org  2008-03-04 05:25 ---
Created an attachment (id=15256)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15256&action=view)
Disallow TFmode and TDmode from reg+reg addressing

This ICE is similar to the one Nathan fixed which is caused by the new 
gcc_assert Joseph added here:

  http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01959.html

I agree with Joseph's suggestion from Comment #5 that we need to disallow
TFmode (and TDmode) similar to Nathan's patch.  This patch fixes the ICE
on the test case.  I'm running a full bootstrap with it now on powerpc64-linux.

* config/rs6000/rs6000.c (rs6000_legitimize_address): Don't generate
reg+reg addressing for TFmode or TDmode quantities.


-- 

bergner at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bergner at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug c++/35394] Agressive template instantiation?

[proy at clg dot qc dot ca]

--- Comment #1 from proy at clg dot qc dot ca  2008-03-04 04:28 ---
For those interested: it might help to know that, on all g++ compilers that I
know of and that have this bug (at least from my understanding of the
situation), one could replace

template 
   class not_compilable
   {
  enum { dummy_value = sizeof (static_assert) };
   };

with

template 
   class not_compilable
   {
  static static_assert dummy_fct ();
  enum { dummy_value = sizeof (dummy_fct ()) };
   };

and it would compile, which (somehow) makes the situation even more
suspicious...

(In reply to comment #0)
> I think recent versions of g++ (4.*, for example, but not 3.4.4) go too far
> performing C++ template instantiation. Mind you, this is only a guess, and you
> guys will know better.
> 
> Here's the problem case. The code shown below should (in my opinion) compile
> properly as is but should not compile when the 2nd line of main() is not
> commented out.
> 
> This «non-compilability» of the 2nd line is made on purpose, to simplify 
> static
> error checking, and relies on a technique similar to the one made by boost's
> static assert on most platforms. The intent is to cause meaningful error
> messages in cases where we can "see them coming", without preventing correct
> programs to compile. In main(), the 1st line is expected to be legal and the
> 2nd (when it's not commented out) is illegal. What I see as a bug here is that
> the code for generic class not_compilable seems to be considered even when the
> code does not use it.
> 
> In more detail: the goal of the test cas below is to provoke a compile-time
> failure that describes the error using the template parameter Reason in 
> generic
> class not_compilable, but only when the static int value used for factorial is
> negative. This test code compiles (or does not compile, depending on the case)
> fine using most compilers at my disposal (g++ 3.3* and 3.4* included) but most
> of my students using g++ 4.* report that this code fails to compile even when
> only the 1st line of main() is there. I would like to give you guys more info
> but all g++ compilers around me seem to handle this correctly; only "recent
> versions" (at least from 4.1* on) seem to mishandle it (at least if one
> considers, as I do, the following technique to be valid C++).
> 
> The code follows...
> 
> // ---
> 
> //
> // static_assert is provided here for clarity; remove it or
> // rename it if it is provided by your compiler
> //
> template 
>struct static_assert;
> template <>
>struct static_assert {};
> 
> //
> // A class made not to compile, on purpose. Since it is generic, my
> // expectation is that it should not be considered if it is not being
> // used. It is syntactically correct and compiles fine (when not used)
> // on older g++ (3.3* to 3.4* at least) and on all compilers at my
> // disposal, as mentioned above
> //
> template 
>class not_compilable
>{
>   enum { dummy_value = sizeof (static_assert) };
>};
> 
> //
> // A class that does compile :)
> //
> struct compilable
> {
> };
> 
> //
> // A static type selector
> //
> template 
>struct static_if_else;
> template 
>struct static_if_else
>{
>   typedef IfTrue type;
>};
> template 
>struct static_if_else
>{
>   typedef IfFalse type;
>};
> 
> //
> // An empty class to add meaning when factorial does
> // not compile using a negative value for N
> //
> class negative_value_not_accepted {};
> 
> //
> // A class that should only compile when N>=0 and that
> // should fail otherwise
> //
> template 
>struct factorial
>   : private static_if_else<
>(N<0), not_compilable, compilable
> >::type
>{
>   enum { value = N * factorial::value };
>};
> template <>
>struct factorial<0>
>{
>   enum { value = 1 };
>};
> 
> //
> // The test program. My understanding is that it should compile
> // when only the 1st line is included and that it should not
> // compile when the 2nd line is included. What I see as a bug is
> // that g++ 4.1*+ seems not to accept even the 1st line, considering
> // not_compilable even though it is not being used by the program...
> //
> #include 
> using std::cout;
> int main ()
> {
>cout << factorial<5>::value; // Cool; should compile
>//cout << factorial<-3>::value; // should not compile
> }
> 


-- 


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

[Bug target/35453] New: nmmintrin.h defines macros SIDD_XXX

[hjl dot tools at gmail dot com]

nmmintrin.h header file contains macros like

#define SIDD_XXX

These need to be named with a leading underscore, as in

#define _SIDD_XXX

since user may define SIDD_XXX.


-- 
   Summary: nmmintrin.h defines macros SIDD_XXX
   Product: gcc
   Version: 4.4.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: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/35452] New: erasing uncessary warning for basic block frequency computation

[zhouyi04 at ios dot cn]

When compiling program like following:
int
fn(int s) {
  int i;

  i = 2;

  if (s)
   i = 1;

  if (s)
   printf("%d\n", i);


  return 0;
}

#cc1 -O2 -fdump-tree-vrp-all hello.c
There will be:
Jumps threaded: 1
Removing basic block 3
;; basic block 3, loop depth 0, count 0
;; prev block 7, next block 4
;; pred:
;; succ:   4 [100.0%]  (fallthru,exec)
Invalid sum of incoming frequencies 0, should be 5000
:;
in hello.c.055t.vrp1 etc.


A patch:
--- gcc/gcc/tree-cfgcleanup.c~  Sat Jan  5 14:45:30 2008
+++ gcc/gcc/tree-cfgcleanup.c   Tue Mar  4 11:11:49 2008
@@ -427,6 +427,9 @@
   else
s = redirect_edge_and_branch (e, dest);

+  bb->frequency -= EDGE_FREQUENCY(e);
+  bb->count -= e->count;
+
   if (s == e)
{
  /* Create arguments for the phi nodes, since the edge was not


Anyone help me to regression test it, because I am not able to 
regression it in current juncture :-)


-- 
   Summary: erasing uncessary warning for basic block frequency
computation
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zhouyi04 at ios dot cn
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error

[mrs at apple dot com]

--- Comment #3 from mrs at apple dot com  2008-03-04 01:19 ---
My bug is related to this, but mine is an ice on valid.


-- 


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

[Bug bootstrap/35451] New: stage2 bootstrap xgcc infinite loop

[oblivian at users dot sourceforge dot net]

When bootstrapping for a new system based off of HLFS using:

Binutils 2.18
Glibc 2.7
Gcc 4.3.0-20080228 (checked out from gcc-4_3-branch)

The host os system for build is:

Binutils 2.17
Glibc 2.5
Gcc 4.1.2

Build order was:

pass 1 4.3.0 bootstrap toolchain with configure of:
  --prefix=/tools \
  --with-local-prefix=/tools --with-pic --disable-nls \
  --disable-libmudflap --disable-libssp \
  --enable-languages=c --enable-checking \
  --enable-werror --enable-bootstrap

glibc 2.7 with a configure of:
  --prefix=/tools \
  --with-binutils=/tools/bin --with-headers=/tools/include \
  --enable-kernel=2.6.0 --enable-bind-now --enable-add-ons \
  --without-gd --with-selinux --with-tls --disable-profile

pass 2 4.3.0 bootstrap toolchain with configure of:
   --prefix=/tools \
   --with-local-prefix=/tools --enable-shared \
   --enable-clocale=gnu --enable-threads=posix \
   --enable-__cxa_atexit --enable-languages=c,c++ \
   --with-lib-path=/tools/lib --disable-libstdcxx-pch \
   --enable-checking --disable-werror

When bootstrapping pass 2 the xgcc for stage1 will go into an infinite loop and
starts to eat all available memory when trying to compile this simple program:

int main(void)
{
  ;
  return 0;
}

running the stage1 xgcc under gdb shows it getting stuck in __kernel_vsyscall.

I can pull the 4.3.0 snapshot out of my build system and replace it with 4.2.3
and it builds with no problems.

I've tried to use binutils-2.18.50.0.4 and glibc-2.7.90 with Fedora patches as
well with no luck (4.3.0 still has the same infinite loop).

I'm thinking from my results that the problem is some where with 4.3.0 being
used to compile 4.3.0, since the initial pass 1 compiler bootstraps ok and is
being built with 4.1.2, and also the 4.2.3 compiles just fine with the
glibc-2.7 and binutils-2.18?

I had to move on so I went forward with 4.2.3 and continued with the build, so
when I get a chance I'll rerun the build with 4.3.0 and pull the build logs and
gdb output.


-- 
   Summary: stage2 bootstrap xgcc infinite loop
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oblivian at users dot sourceforge dot net
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-04 00:58 ---
*** Bug 35450 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mrs at apple dot com


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

[Bug c++/35450] ice on valid template

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-03-04 00:58 ---


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


-- 

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

[Bug c++/35450] ice on valid template

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-04 00:56 ---
This was just filed in a different bugzilla recently too.  I had it in a file
called t.cc and I started to paste this testcase there and I was, wait a minute
this is the same testcase.


-- 


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

[Bug c++/35450] New: ice on valid template

[mrs at apple dot com]

#include 

struct test_a{ void load(){} };
struct test_b{ };

template  class Concept, typename Model>
struct models
{

typedef char (&yes)[2];
typedef char no;

template  class C, typename M, typename C::type
P = 0>
struct hint
{ };

template 
static yes test(M*, hint * = 0);
static no  test(...);

static const bool value = (sizeof(test((Model*)0))==sizeof(yes));
};

template 
struct member
{
typedef Type Class::* type;
};

template 
struct loadable
{ };


int main()
{
std::cout << models::value << std::endl;
}

# with 4.2.1:
$ g++-4.2 t.cc
t.cc: In instantiation of ‘models’:
t.cc:37:   instantiated from here
t.cc:14: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://developer.apple.com/bugreporter> for instructions.

And the same with a compiler from today as well:
$ /Volumes/pool1/mrs/packages/gcc-20080308/bin/g++ t.cc
t.cc: In instantiation of ‘models’:
t.cc:37:   instantiated from here
t.cc:14: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This works on comeau.

radr://5772368


-- 
   Summary: ice on valid template
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug c/35427] pointer subtraction in very big array

[akr at m17n dot org]

--- Comment #4 from akr at m17n dot org  2008-03-04 00:17 ---
The result can be representable by ptrdiff_t
because the result is number of longs.

The array is bit larger than 2**31 bytes.
So the result is bit larger than 2**29.
It is representable in signed.


-- 


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #15 from pcarlini at suse dot de  2008-03-04 00:09 ---
(In reply to comment #14)
> Hi,
> this is what I get from our thester:
> 
> Differences:
> Tests that now work, but didn't before:
> abi_check
> 
> so it ought to make differnece for i686-linux.

Note however, that the patch also didn't help Geoff's i686-linux tester, just
have a look to gcc-testresults.

> It is quite possible that things differ on 64bit hosts, we are staying
> on quite fragile ground here because in the current cost metric the
> benefits of inlining are very close to costs. Given the nature that
> function call of the wrapped function is a bit chepaer than call of the
> wrapper is quite correct.
> 
> The decision on whether function should be inlined or not depends on
> many things, like overall size, ABI details etc.  I see it is quite
> irritating for ABI checking.

I think we should not mix the two issues, here. The first issue is that, IMO,
the function we are discussing should be inlined, it's very small and we always
inlined it until recently.

The other issue is the ABI check failure. I said issue, but actually it's
really trivial, just matter of tweaking a bit the linker script, making it a
little more tight. I don't think much more is necessary.


-- 


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

[Bug c/35427] pointer subtraction in very big array

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-03 23:57 ---
ptrdiff_t is defined as a signed type so is the subtraction of two pointer
types.


-- 


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

[Bug fortran/33197] Fortran 2008: math functions and other small changes

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2008-03-03 23:51 
---
Tobias noted the following also need updating:

3999:  /* Fortran 2008 draft allows BIND(C) for internal procedures.  */
4000-  if (gfc_current_state () == COMP_CONTAINS
4001- && sym->ns->proc_name->attr.flavor != FL_MODULE
4002- && gfc_notify_std (GFC_STD_GNU, "Extension: BIND(C) attribute at %L "
4003-"may not be specified for an internal procedure",
--
4733:  /* The following is allowed in the Fortran 2008 draft.  */
4734-  if (gfc_current_state () == COMP_CONTAINS
4735- && sym->ns->proc_name->attr.flavor != FL_MODULE
4736- && gfc_notify_std (GFC_STD_GNU, "Extension: BIND(C) attribute at "
4737-"%L may not be specified for an internal
procedure",

ERF and ERFC should be simplified, it's easy since MPFR has these functions.

And, quoting my comment #6:
"Two more remarks on that: ASINH, ACOSH and ATANH need to accept COMPLEX
arguments. Some other functions also should be extended that way (ASIN, ACOS...
and probably many more).

Also, one very annoying feature: BESSEL_JN and BESSEL_YN have two forms, with 2
or 3 arguments. What's more, these two forms have very different properties
(the first one is elemental, the second one is transformational), and I don't
know how to implement that in the current handling of intrinsics!"


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |
   |patches/2008-   |
   |02/msg01430.html|
   Keywords|patch   |
Summary|Fortran 2008: gamma() and   |Fortran 2008: math functions
   |other small changes |and other small changes


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

[Bug c/35449] New: extended asm documentation wrong

[mrs at apple dot com]

In doc/extend.texi we have:

int foo ()
@{
  int x = 42;
  int *y = &x;
  int result;
  asm ("magic stuff accessing an 'int' pointed to by '%1'"
"=&d" (r) : "a" (y), "m" (*y));
  return result;
@}

two problems, r != result.  Second problem, there should be a : before the
output constraint.

The current docs on the web site are unchanged.


-- 
   Summary: extended asm documentation wrong
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug fortran/33197] Fortran 2008: gamma() and other small changes

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2008-03-03 23:46 
---
Subject: Bug 33197

Author: fxcoudert
Date: Mon Mar  3 23:46:20 2008
New Revision: 132846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132846
Log:
PR fortran/33197

gcc/fortran/
* intrinsic.c (add_functions): Modify intrinsics ACOSH, ASINH,
ATANH, ERF, ERFC and GAMMA. Add intrinsics BESSEL_{J,Y}{0,1,N},
ERFC_SCALED, LOG_GAMMA and HYPOT.
* intrinsic.h (gfc_check_hypot, gfc_simplify_hypot,
gfc_resolve_hypot): New prototypes.
* mathbuiltins.def: Add HYPOT builtin. Make complex versions of
ACOSH, ASINH and ATANH available.
* gfortran.h (GFC_ISYM_ERFC_SCALED, GFC_ISYM_HYPOT): New values.
* lang.opt: Add -std=f2008 option.
* libgfortran.h: Define GFC_STD_F2008.
* lang-specs.h: Add .f08 and .F08 file suffixes.
* iresolve.c (gfc_resolve_hypot): New function.
* parse.c (parse_contained): Allow empty CONTAINS for Fortran 2008.
* check.c (gfc_check_hypot): New function.
* trans-intrinsic.c (gfc_intrinsic_map): Define ERFC_SCALE builtin.
* options.c (set_default_std_flags): Allow Fortran 2008 by default.
(form_from_filename): Add .f08 suffix.
(gfc_handle_option): Handle -std=f2008 option.
* simplify.c (gfc_simplify_hypot): New function.
* gfortran.texi: Document Fortran 2008 status and file extensions.
* intrinsic.texi: Document new BESSEL_{J,Y}{0,1,N} intrinsics,
as well as HYPOT and ERFC_SCALED. Update documentation of ERF,
ERFC, GAMMA, LGAMMA, ASINH, ACOSH and ATANH.
* invoke.texi: Document the new -std=f2008 option.

libgomp/
* testsuite/libgomp.fortran/fortran.exp: Add .f08 and
.F08 file suffixes.

gcc/testsuite/
* gfortran.dg/gomp/gomp.exp: Add .f08 and .F08 file suffixes.
* gfortran.dg/dg.exp: Likewise.
* gfortran.dg/vect/vect.exp: Likewise.
* gfortran.fortran-torture/execute/execute.exp: Likewise.
* gfortran.fortran-torture/compile/compile.exp: Likewise.
* gfortran.dg/gamma_1.f90: Also check log_gamma.
* gfortran.dg/invalid_contains_1.f90: Remove warning about
empty CONTAINS.
* gfortran.dg/gamma_2.f90: Add a few error messages.
* gfortran.dg/invalid_contains_2.f90: Remove warning about
empty CONTAINS.
* gfortran.dg/gamma_3.f90: Adjust error message.
* gfortran.dg/gamma_4.f90: Test for log_gamma instead of lgamma.
* gfortran.dg/bind_c_usage_9.f03: Adjust error messages.
* gfortran.dg/bessel_1.f90: New test.
* gfortran.dg/recursive_check_3.f90: Remove warnings.
* gfortran.dg/besxy.f90: Also check for new F2008 intrinsics.
* gfortran.dg/derived_function_interface_1.f90: Remove warning.
* gfortran.dg/contains_empty_1.f03: New test.
* gfortran.dg/erfc_scaled_1.f90: New test.
* gfortran.dg/hypot_1.f90: New test.
* gfortran.dg/contains_empty_2.f03: New test.

libgfortran/
* intrinsics/erfc_scaled_inc.c: New file.
* intrinsics/erfc_scaled.c: New file.
* gfortran.map (GFORTRAN_1.0): Add _gfortran_erfc_scaled_r*.
* Makefile.am: Add intrinsics/erfc_scaled.c.
* config.h.in: Regenerate.
* configure: Regenerate.
* Makefile.in: Regenerate.

Added:
trunk/gcc/testsuite/gfortran.dg/bessel_1.f90
trunk/gcc/testsuite/gfortran.dg/contains_empty_1.f03
trunk/gcc/testsuite/gfortran.dg/contains_empty_2.f03
trunk/gcc/testsuite/gfortran.dg/erfc_scaled_1.f90
trunk/gcc/testsuite/gfortran.dg/hypot_1.f90
trunk/libgfortran/intrinsics/erfc_scaled.c
trunk/libgfortran/intrinsics/erfc_scaled_inc.c
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/lang-specs.h
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/mathbuiltins.def
trunk/gcc/fortran/options.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/besxy.f90
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_9.f03
trunk/gcc/testsuite/gfortran.dg/derived_function_interface_1.f90
trunk/gcc/testsuite/gfortran.dg/dg.exp
trunk/gcc/testsuite/gfortran.dg/gamma_1.f90
trunk/gcc/testsuite/gfortran.dg/gamma_2.f90
trunk/gcc/testsuite/gfortran.dg/gamma_3.f90
trunk/gcc/testsuite/gfortran.dg/gamma_4.f90
trunk/gcc/testsuite/gfortran.dg/gomp/gomp.exp
trunk/gcc/testsuite/gfortran.dg/invalid_contains_1.f90
trunk/gcc/testsuite/gfortran.dg/invalid_contains_2.f90
trunk/gcc/t

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[hubicka at ucw dot cz]

--- Comment #14 from hubicka at ucw dot cz  2008-03-03 23:46 ---
Subject: Re:  [4.4 Regression]: FAIL: abi_check

> Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
> machines I'm not seeing any progress :(
Hi,
this is what I get from our thester:

Differences:
Tests that now work, but didn't before:
abi_check

so it ought to make differnece for i686-linux.

It is quite possible that things differ on 64bit hosts, we are staying
on quite fragile ground here because in the current cost metric the
benefits of inlining are very close to costs. Given the nature that
function call of the wrapped function is a bit chepaer than call of the
wrapper is quite correct.

The decision on whether function should be inlined or not depends on
many things, like overall size, ABI details etc.  I see it is quite
irritating for ABI checking.

I am sending it for testing for x86-64 now. Perhaps we can deal with
this by checking ABI with -Os that is a bit less dependent on fine
grained performance decision, like we are seeing here?

Honza


-- 


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

[Bug c/35427] pointer subtraction in very big array

[akr at m17n dot org]

--- Comment #2 from akr at m17n dot org  2008-03-03 23:45 ---
(In reply to comment #1)
> nelem*sizeof(long)
> 
> Wraps so what do you expect?  This is the correct behavior really.

Oops.  It wrapped.

But changing the type of nelem to size_t doesn't change the situation.

nelem * sizeof(long) < 2**32, so it doesn't wraps size_t.

Anyway malloc's argument is size_t.
So we can pass a size bigger than 2**31 bytes and malloc can allocates it.


-- 


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

[Bug fortran/35285] Failures in the NIST test suite FM827 with -m64

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2008-03-03 23:26 
---
(In reply to comment #5)
> Was it decided this is a platform specific library issue, not gfortran?

I think it's likely, but to be sure we need some more input. Dominique, could
you try to print out the values of the different parts of the calculation of
dvd and avd, to see which function call gives the wrong value?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug testsuite/31342] testsuite i386/pic-1.c FAILed for warning -fPIC ignored

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2008-03-03 23:18 ---
I see the test failing on i686-mingw32, but it's more complicated than just
failing for the given warning.

The warning is given, and pruned by core DejaGnu's prune_warnings.  This means
that { dg-require-effective-target fpic } passes, and all tests using the -fPIC
option are allowed to run.  Most of them pass just fine.  This particular test,
however, expects a diagnostic which is missing (probably because Windows PIC is
different from the sort of PIC expected and so flag_pic is forced to 0 after
issuing the warning).  The actual failure is:

FAIL: gcc.target/i386/pic-1.c  (test for errors, line 11)

If the test is indeed inapplicable to Windows (if the asm is valid on Windows
and should not be diagnosed), the right solution would be to skip this test on
Windows targets.  The Windows target maintainers should be able to confirm the
correct fix.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-03-03 23:18:17
   date||


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

[Bug middle-end/35413] [meta-bug] Remaining issues blocking the removal of libcall notes from the compiler

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2008-03-03 23:04 
---
I think that -ftrapv should not be considered blocking for this purpose.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug libgomp/33131] [4.2 regression] libgomp/env.c:60: warning: implicit declaration of function 'strncasecmp'

[rwild at gcc dot gnu dot org]

--- Comment #7 from rwild at gcc dot gnu dot org  2008-03-03 22:35 ---
Subject: Bug 33131

Author: rwild
Date: Mon Mar  3 22:35:13 2008
New Revision: 132844

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132844
Log:
2008-03-03  Peter O'Gorman  <[EMAIL PROTECTED]>

PR libgomp/33131
* configure.ac: Add ACX_HEADER_STRING.
* env.c: Include strings.h.
* aclocal.m4: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/Makefile.in
trunk/libgomp/aclocal.m4
trunk/libgomp/config.h.in
trunk/libgomp/configure
trunk/libgomp/configure.ac
trunk/libgomp/env.c
trunk/libgomp/testsuite/Makefile.in


-- 


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

[Bug tree-optimization/35428] [4.3/4.4 regression] ICE with "-ftrapv"

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c/35448] [4.3/4.4 regression] ICE with fixed-point constants

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug c/35448] New: [4.3/4.4 regression] ICE with fixed-point constants

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE on mainline and the
4.3 branch:

==
void foo()
{
  0.2r == 0.2hr;
}
==

bug.c: In function 'foo':
bug.c:3: sorry, unimplemented: GCC cannot support operators with integer types
and fixed-point types that have too many integral and fractional bits together
bug.c:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3/4.4 regression] ICE with fixed-point constants
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35447] [4.1/4.2/4.3/4.4 regression] ICE with broken statement expression

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35447] New: [4.1/4.2/4.3/4.4 regression] ICE with broken statement expression

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.1.0:

==
void foo()
{
  ({ int i().; });
}
==

bug.c: In function 'i':
bug.c:3: error: expected declaration specifiers before '.' token
bug.c:3: error: expected declaration specifiers before '}' token
bug.c:3: error: expected declaration specifiers before ')' token
bug.c:4: error: expected declaration specifiers before '}' token
bug.c:4: error: expected '{' at end of input
bug.c: In function 'foo':
bug.c:4: error: expected declaration or statement at end of input
bug.c:4: internal compiler error: tree check: expected bind_expr, have
decl_expr in c_finish_stmt_expr, at c-typeck.c:7649
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with broken statement
expression
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35446] [4.1/4.2/4.3/4.4 regression] ICE with invalid array initializer

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35446] New: [4.1/4.2/4.3/4.4 regression] ICE with invalid array initializer

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.1.0:

===
int a[2][2] = { [0 ... 1] = { ; } };
===

bug.c:1: error: expected expression before ';' token
bug.c:1: internal compiler error: in finish_init, at c-typeck.c:5158
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with invalid array
initializer
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35445] [4.1/4.2/4.3/4.4 regression] ICE with conflicting declarations

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35445] New: [4.1/4.2/4.3/4.4 regression] ICE with conflicting declarations

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.1:

===
extern int i;
extern int i;
int i[] = {};
===

bugI6.c:3: error: conflicting types for 'i'
bugI6.c:2: error: previous declaration of 'i' was here
bugI6.c:3: internal compiler error: in composite_type, at c-typeck.c:306
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with conflicting
declarations
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35444] [4.1/4.2/4.3/4.4 regression] ICE with invalid function declaration

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35444] New: [4.1/4.2/4.3/4.4 regression] ICE with invalid function declaration

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.1.0:

===
void foo(int n, int a[n], int 0);
void bar() {}
===

bug.c:1: error: expected ';', ',' or ')' before numeric constant
bug.c:2: internal compiler error: in put_pending_sizes, at stor-layout.c:108
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with invalid function
declaration
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35443] [4.1/4.2/4.3/4.4 regression] Completely broken diagnostic with bind_expr

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||35441
   Target Milestone|--- |4.1.3


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

[Bug c/35443] New: [4.1/4.2/4.3/4.4 regression] Completely broken diagnostic with bind_expr

[reichelt at gcc dot gnu dot org]

A broken diagnostic is issued for the following invalid code snippet
since GCC 4.1.0:

==
void foo()
{
  ({ int i; })();
}
==

#'bind_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:3: error: called object  is not a function

Similar to PR35441.


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] Completely broken
diagnostic with bind_expr
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35442] [4.1/4.2/4.3/4.4 regression] Completely broken diagnostic with view_convert_expr

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||35441
   Target Milestone|--- |4.1.3


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

[Bug c/35442] New: [4.1/4.2/4.3/4.4 regression] Completely broken diagnostic with view_convert_expr

[reichelt at gcc dot gnu dot org]

A broken diagnostic is issued for the following invalid code snippet
since GCC 4.0.2:

==
typedef char A __attribute__((vector_size(8)));
typedef int  B __attribute__((vector_size(8)));

void foo(A a)
{
  ((B)a)();
}
==

#'view_convert_expr' not supported by pp_c_expression#'bugD3.c: In function
'foo':
bug.c:6: error: called object  is not a function
bug.c:5: warning: MMX vector argument without MMX enabled changes the ABI

Similar to PR35441.


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] Completely broken
diagnostic with view_convert_expr
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35441] [4.1/4.2/4.3/4.4 regression] Completely broken diagnostics

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35441] New: [4.1/4.2/4.3/4.4 regression] Completely broken diagnostics

[reichelt at gcc dot gnu dot org]

A broken diagnostic is issued for the following invalid code snippet
since GCC 4.0.0:


void foo(char **p, char **q)
{
  (p - q)();
}


With GCC 4.0.x we got 

bug.c: In function 'foo':
bug.c:3: error: called object '#'exact_div_expr' not supported by
pp_c_expression#' is not a function

which is already bad enough. But since GCC 4.1.0 it's even worse:

#'exact_div_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:3: error: called object  is not a function

Not only the exact_div_expr case should be fixed, but also the output
order when we hit something unsupported. And, yes, there are more cases
of unsupported expressions. How about the following?


void foo(char *p, char *q)
{
  (p < q ? p : q)();
}


#'min_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:3: error: called object  is not a function


void foo(double x, double y)
{
  (x/y)();
}


#'rdiv_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:3: error: called object  is not a function


void foo(unsigned i, int j)
{
  (i << j | i >> (32 - j))();
  (i >> j | i << (32 - j))();
}


#'lrotate_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:3: error: called object  is not a function
#'rrotate_expr' not supported by pp_c_expression#'bug.c:4: error: called object
 is not a function


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] Completely broken
diagnostics
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35440] [4.1/4.2/4.3/4.4 regression] ICE resulting in completely broken diagnostic

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35440] New: [4.1/4.2/4.3/4.4 regression] ICE resulting in completely broken diagnostic

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.1.0:


struct A {};

void foo()
{
  (struct A){}();
}


The compiler crashes trying to emit an error message, which results in a
completely broken diagnostic (e.g. file name and "internal compiler error"
message are missing):

'{
In function 'foo':
tree check: expected class 'expression', have 'exceptional' (constructor) in
pp_c_initializer_list, at c-pretty-print.c:1182
Please submit a full bug report, [etc.]

Before GCC 4.1.0 we got the error message:
bug.c: In function 'foo':
bug.c:5: error: called object '{}' is not a function


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE resulting in completely
broken diagnostic
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, diagnostic, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include

[bugzilla-gcc at thewrittenword dot com]

--- Comment #19 from bugzilla-gcc at thewrittenword dot com  2008-03-03 
21:12 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00162.html


-- 


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

[Bug c/35439] New: ICE using threadprivate for broken variable

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with "-fopenmp":


void x[1];
#pragma omp threadprivate(x)


bug.c:1: error: declaration of 'x' as array of voids
bug.c:2: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in c_parser_omp_threadprivate, at c-parser.c:7971
Please submit a full bug report, [etc.]

Related to PR35428.


-- 
   Summary: ICE using threadprivate for broken variable
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35438] New: ICE with invalid use of threadprivate

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with "-fopenmp":


void foo();
#pragma omp threadprivate(foo)


bug.c:2: internal compiler error: tree check: expected var_decl, have
function_decl in c_parser_omp_threadprivate, at c-parser.c:7975
Please submit a full bug report, [etc.]


-- 
   Summary: ICE with invalid use of threadprivate
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored, openmp
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35437] [4.1/4.2/4.3/4.4 regression] ICE with struct containing incomplete type

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35437] New: [4.1/4.2/4.3/4.4 regression] ICE with struct containing incomplete type

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.0:

===
struct A
{
  int i;
  struct A a;
};

void foo()
{
  struct A b = { 0 };
}
===

bug.c:4: error: field 'a' has incomplete type
bug.c: In function 'foo':
bug.c:9: internal compiler error: in count_type_elements, at expr.c:5001
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with struct containing
incomplete type
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35436] [4.1/4.2/4.3/4.4 regression] ICE with attribute "format"

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35435] [4.1/4.2/4.3/4.4 regression] ICE with attribute tls_model in typedef

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35435] New: [4.1/4.2/4.3/4.4 regression] ICE with attribute tls_model in typedef

[reichelt at gcc dot gnu dot org]

The following (valid?) code snippet triggers an ICE since GCC 3.3:

==
typedef int X __attribute__((tls_model("initial-exec")));
==

bug.c:1: internal compiler error: tree check: expected var_decl, have type_decl
in handle_tls_model_attribute, at c-common.c:5936
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with attribute
tls_model in typedef
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/35434] [4.2/4.3/4.4 regression] ICE with attribute alias/weakref

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.4


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

[Bug c/35434] New: [4.2/4.3/4.4 regression] ICE with attribute alias/weakref

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.2.0:

===
typedef int i __attribute__((alias("j")));
===

bug.c:1: internal compiler error: in make_decl_rtl, at varasm.c:1267
Please submit a full bug report, [etc.]

Before GCC 4.2.0 we got the error:
bug.c:1: error: 'i' defined both normally and as an alias


A similar code snippet causes a crash in a different location:

===
typedef int i __attribute__((weakref("j")));
===

bug.c:1: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:160
Please submit a full bug report, [etc.]

Before GCC 4.2.0 we got the error:
bug.c:1: error: weak declaration of 'i' must be public
bug.c:1: error: 'i' defined both normally and as an alias


-- 
   Summary: [4.2/4.3/4.4 regression] ICE with attribute
alias/weakref
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug tree-optimization/35428] [4.3/4.4 regression] ICE with "-ftrapv"

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2008-03-03 20:29 
---
> This is caused by the vectorizer.

Indeed. The ICE appears also with "-ftrapv -O -ftree-vectorize".
(This still compiles fine on the 4.2 branch.)


-- 


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

[Bug c/35433] [4.1/4.2/4.3/4.4 regression] ICE with typeof and ternary operator

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c/35433] New: [4.1/4.2/4.3/4.4 regression] ICE with typeof and ternary operator

[reichelt at gcc dot gnu dot org]

The following (IMHO valid) code snippet triggers an ICE since GCC 4.1.0:


typedef int* X;
typedef int* Y;

X (*p)[][0];
Y (*q)[][0];

typeof(*(0 ? p : q)) x = { 0 };


bug.c:7: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

The code compiled fine with GCC 2.95.3, crashed GCC 3.0.0, 3.0.1,
and was rejected by GCC 3.0.2 - 4.0.4.


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with typeof and ternary
operator
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/35432] [4.1/4.2/4.3/4.4 regression] ICE with zero-sized array

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug middle-end/35432] New: [4.1/4.2/4.3/4.4 regression] ICE with zero-sized array

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE since GCC 4.1.0:


struct A
{
  char c[0];
};

void foo(struct A a)
{
  (a = a).c;
}


bug.c: In function 'foo':
bug.c:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with zero-sized array
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug tree-optimization/35428] [4.3/4.4 regression] ICE with "-ftrapv"

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2008-03-03 20:14 ---
Subject: Re:   New: [4.3/4.4 regression] ICE with "-ftrapv"

This is caused by the vectorizer.

Sent from my iPhone

On Mar 3, 2008, at 11:50, "reichelt at gcc dot gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

> The following valid code snippet triggers an ICE on mainline and 4.3  
> branch
> when compiled with "-ftrapv -O3"

-- Pinski


-- 


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

Re: [Bug tree-optimization/35428] New: [4.3/4.4 regression] ICE with "-ftrapv"

[Andrew Pinski]

This is caused by the vectorizer.

Sent from my iPhone

On Mar 3, 2008, at 11:50, "reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED] 
> wrote:


The following valid code snippet triggers an ICE on mainline and 4.3  
branch

when compiled with "-ftrapv -O3"


-- Pinski

[Bug tree-optimization/35431] [4.1/4.2/4.3/4.4 regression] ICE with complex data

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug tree-optimization/35431] New: [4.1/4.2/4.3/4.4 regression] ICE with complex data

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE since GCC 4.1.0 when compiled
with "-O2":


void bar();

void foo(int i)
{
  __complex__ int k = 0;

  if (i)
k = 1;

  for (i = 0; i < 1; ++i)
;

  if (k)
bar();
}


bug.c: In function 'foo':
bug.c:4: internal compiler error: tree check: expected value_handle, have
ssa_name in bitmap_set_contains_value, at tree-ssa-pre.c:744
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with complex data
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/35430] [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug middle-end/35430] New: [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE since GCC 4.0.0 when compiled
with "-W":


void foo(__complex__ int i)
{
  i == 0u;
}


bug.c: In function 'foo':
bug.c:3: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have
complex_type in int_fits_type_p, at tree.c:6173
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/35429] [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug tree-optimization/35429] New: [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE since GCC 4.1.0 when compiled
with "-O":


int foo(__complex__ int z0, __complex__ int z1)
{
  return z0 != 0 || z1 != 0;
}


bug.c: In function 'foo':
bug.c:3: internal compiler error: in build_int_cst_wide, at tree.c:891
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/35425] Improve -mpcXXX handling

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-03-03 19:52 ---
You can put all arguments that use atoi() to this PR:

-mregparm=aaa, -mbranch-cost=foo, -mpreferred-stack-boundary=10^5, ...

Do we really need to fix this?


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

Summary|Improve -mpcXXX handling|Improve -mpcXXX handling


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

[Bug tree-optimization/35428] [4.3/4.4 regression] ICE with "-ftrapv"

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/35428] New: [4.3/4.4 regression] ICE with "-ftrapv"

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with "-ftrapv -O3":


void foo(int x[])
{
  int i, j;

  for (i = 0; i < 2; i++)
for (j = 0; j < 2; j++)
{
  x[i] = x[i*j];
  x[i] = x[i*j];
}
}


bug.c: In function 'foo':
bug.c:2: internal compiler error: tree check: expected integer_cst, have
polynomial_chrec in int_cst_value, at tree.c:7968
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3/4.4 regression] ICE with "-ftrapv"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2008-03-03 19:35 ---
Quoting your insn once more:

(insn 58 57 59 6 gnu/java/nio/natVMSelector.cc:82 (parallel [
(set (reg:DI 4 si [165])
(mult:DI (zero_extend:DI (reg:SI 0 ax))
(zero_extend:DI (reg:SI 2 cx [166]
(clobber (reg:CC 17 flags))
]) 304 {*umulsidi3_insn} (expr_list:REG_DEAD (reg:SI 2 cx [166])
(expr_list:REG_DEAD (reg:SI 0 ax)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (mult:DI (zero_extend:DI (reg:SI 0 ax))
(const_int 1000 [0x3e8]))
(nil))

The register allocator failed to make your insn satisfy its constraints.
Operand 0 is (reg:DI 4 si) but the constraint for it is "=A", i.e. the ax
register.

The funny thing is that reload wants to make operand 0 be (reg:DI 0 ax), but
somehow it can't, even though (reg:SI 0 ax) dies in this insn. So apparently
the high part of (reg:DI 0 ax), i.e. (reg:SI 1 dx), lives across the insn.

This looks to me like a case of PR35404.  What do you think, Ian?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet||[EMAIL PROTECTED],
   ||[EMAIL PROTECTED]


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[pcarlini at suse dot de]

--- Comment #13 from pcarlini at suse dot de  2008-03-03 19:04 ---
Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
machines I'm not seeing any progress :(


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug java/35410] clone() for array types has incorrect return type

[debian-gcc at lists dot debian dot org]

--- Comment #3 from debian-gcc at lists dot debian dot org  2008-03-03 
17:57 ---
an ecj update to 20080303 from the R3_3_maintenance branch doesn't help.


-- 


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

[Bug c/35427] pointer subtraction in very big array

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-03 17:49 ---
nelem*sizeof(long)

Wraps so what do you expect?  This is the correct behavior really.


-- 

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

[Bug c/35427] New: pointer subtraction in very big array

[akr at m17n dot org]

I found that an result of pointer subtraction in a big array is negative when
it is expected to be positive.

% cat t.i
typedef int ptrdiff_t;
typedef unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__malloc__));
extern void exit (int __status) __attribute__ ((__noreturn__));
extern int printf (__const char *__restrict __format, ...);
extern void perror (__const char *__s);

int main(int argc, char **argv)
{
  long *p, *q;
  int nelem;
  ptrdiff_t s;

  printf("sizeof(long) = %d\n", sizeof(long));
  printf("sizeof(size_t) = %d\n", sizeof(size_t));
  printf("sizeof(ptrdiff_t) = %d\n", sizeof(ptrdiff_t));

  nelem = 513 * 1024 * 1024;
  printf("nelem: %d\n", nelem);

  q = malloc(sizeof(long) * nelem);
  if (!q) { perror("malloc"); exit(1); }

  p = q + (nelem-1);
  s = p - q;
  printf("result: %d\n", s);

  return 0;
}
% bin/gcc -Wall t.i
% ./a.out 
sizeof(long) = 4
sizeof(size_t) = 4
sizeof(ptrdiff_t) = 4
nelem: 537919488
result: -535822337
% uname -srv
Linux 2.6.23.12 #3 SMP PREEMPT Thu Dec 27 21:28:19 JST 2007

This program allocates a big array, 513  * 1024 * 1024 elements of longs.

After that, the program subtracts the pointer to the first element from the
last element.

Then the subtraction from the pointer to one after the last element by the
pointer to the first element.
It's result should be 513 * 1024 * 1024 - 1. 
But -535822337 is printed.

Note that the expected result is representable in int because it is counted as
number of longs, not chars.


-- 
   Summary: pointer subtraction in very big array
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: akr at m17n dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/35426] GCC 4.3.0 ICE on valid code in init2.c

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-03-03 17:02 ---
(In reply to comment #2)
> Oh, and both versions were built with mpfr 2.2.1, which configure told me was
> "buggy but acceptable" (if I remember the wording correctly) - is this my
> problem?

I think so.  Can you try to update mpfr and try again?


-- 


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

[Bug c/35426] GCC 4.3.0 ICE on valid code in init2.c

[lloyd at randombit dot net]

--- Comment #2 from lloyd at randombit dot net  2008-03-03 16:57 ---
Oh, and both versions were built with mpfr 2.2.1, which configure told me was
"buggy but acceptable" (if I remember the wording correctly) - is this my
problem?


-- 


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

[Bug c/35426] GCC 4.3.0 ICE on valid code in init2.c

[lloyd at randombit dot net]

--- Comment #1 from lloyd at randombit dot net  2008-03-03 16:55 ---
Created an attachment (id=15255)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15255&action=view)
Testcase


-- 


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

[Bug c/35426] New: GCC 4.3.0 ICE on valid code in init2.c

[lloyd at randombit dot net]

A simple C source fails with an ICE with 4.3.0 (the 20070907 and 20080228
snapshots) with optimizations (-O1/-O2/-Os -- I haven't narrowed it down to
which exact optimization though). This machine is x86-64 but the same assertion
occurs targeting both x86-64 (-m64) and x86 (-m32). Fedora Core 5 machine,
system binutils 2.6.91.0.6. Same file compiles and executes with optimizations
with GCC 4.1.1

$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3-20080228/configure --prefix=/home/jack/opt
--with-mpfr=/home/jack/opt
Thread model: posix
gcc version 4.3.0 20080228 (prerelease) (GCC) 

$ gcc -O2 speed.c -lm -o speed
init2.c:38:  assertion failed: ((32 - 0)+0) == (((32 - 0)+0)/8) * 8 &&
sizeof(mp_limb_t) == (((32 - 0)+0)/8)
speed.c: In function ‘main’:
speed.c:16: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
distcc[28444] ERROR: compile speed.c on localhost failed

The file in question is simple enough that I'm definitely thinking this may be
a build issue - it looks like any code calling libm functions fails with this
problem? It doesn't appear to be anything in FC5's math.h; removing the include
of math.h and explicitly declaring pow() had no effect.


-- 
   Summary: GCC 4.3.0 ICE on valid code in init2.c
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lloyd at randombit dot net
 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=35426

[Bug c++/35057] Integer variable value lost due to optimizations?

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-03-03 16:37 ---
  basic_endpoint()
: data_()
  {
asio::detail::sockaddr_in4_type& data
  = reinterpret_cast(data_);
data.sin_family = 2;
data.sin_port = 0;
data.sin_addr.s_addr = ((in_addr_t) 0x);
  }

you are violating C/C++ type-based aliasing rules here (and in other places).


-- 

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

[Bug c++/35057] Integer variable value lost due to optimizations?

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-03-03 16:34 ---
No, we only confirm bugs once they have a reduced testcase.


-- 


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

[Bug target/35222] [4.3/4.4 Regression] EH output contains procedure label without P' selector

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2008-03-03 
16:33 ---
Subject: Re:  [4.3/4.4 Regression] EH output contains procedure label without
P' selector

The same fail occurs on hpux11 if I disable the use of secondary
definition symbols for one-only support.

Have tested all the alternatives that I can think of for the EH
encoding (pc-relative, indirect through function descriptor, etc)
and they all lead to linker warnings and segmentation faults linking
shared libraries.  So, I believe that the only viable work around
is to force the use of sjlj exceptions.

I'm testing a patch to configure.ac to do this and will submit as
soon as I know that libstdc++ links successfully..

Dave


-- 


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

[Bug c++/35057] Integer variable value lost due to optimizations?

[olafvdspek at gmail dot com]

--- Comment #3 from olafvdspek at gmail dot com  2008-03-03 16:30 ---
Hmm, should I change the status back to NEW manually?


-- 

olafvdspek at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug testsuite/20360] 20021014-1.c fails on account of unsupported build option

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-03-03 16:29 ---
(In reply to comment #6)
> gcc-3.4.4 testsuite still shows the failure; none of the proposed fixes were
> applied.

yes and 3.4.x is no longer maintained (4.0.x likewise).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

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

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-03-03 16:22:34
   date||


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug target/35222] [4.3/4.4 Regression] EH output contains procedure label without P' selector

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2008-03-03 16:22:12
   date||


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

[Bug middle-end/35193] [4.3/4.4 Regression] can't find a register in class 'R1_REGS' while reloading 'asm'

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/35325] [4.3/4.4 regression] ICE with fixed-point types in template parameter

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-03-03 16:28:08
   date||


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

[Bug c++/35262] [4.4 Regression]: FAIL: abi_check

[hubicka at gcc dot gnu dot org]

--- Comment #11 from hubicka at gcc dot gnu dot org  2008-03-03 16:21 
---
Subject: Bug 35262

Author: hubicka
Date: Mon Mar  3 16:20:31 2008
New Revision: 132838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132838
Log:
PR c++/35262
* ipa-inline.c (cgraph_decide_inlining_of_small_function): Be more
aggressive on inlining cold calls.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c


-- 


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

[Bug c++/35323] [4.3 regression] ICE calling functions with fixed-point type parameter

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/31041] [4.3 Regression] verify_stmts failed: invalid operand to binary operator with -O2 -ftree-vectorize

[tprince at computer dot org]

--- Comment #8 from tprince at computer dot org  2008-03-03 16:20 ---
pr31341 has a patch attached to allow the test case to run on targets where
there is checking for conflicts with stdint.h


-- 


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

[Bug preprocessor/35322] [4.2/4.3/4.4 regression] ICE with incomplete macro

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/35321] [4.1/4.2/4.3/4.4 regression] ICE with invalid use of __builtin_offsetof

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-03-03 16:26:46
   date||


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

[Bug testsuite/20360] 20021014-1.c fails on account of unsupported build option

[tprince at computer dot org]

--- Comment #6 from tprince at computer dot org  2008-03-03 16:26 ---
gcc-3.4.4 testsuite still shows the failure; none of the proposed fixes were
applied.


-- 

tprince at computer dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug c++/35320] [4.1/4.2/4.3/4.4 regression] ICE with invalid friend declaration

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-03-03 16:26:12
   date||


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

[Bug c++/35319] [4.3/4.4 regression] ICE throwing fixed-point types

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-03-03 16:25:48
   date||


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