[Bug c/36941] gcc does not reject invalid cast

[sabre at nondot dot org]

--- Comment #5 from sabre at nondot dot org  2008-07-26 05:10 ---
Ok, so is it right or wrong? :)


-- 


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

[Bug fortran/36942] iostat and/or end= and Err= don't work in read statements, unformatted reads

[kargl at gcc dot gnu dot org]

--- Comment #7 from kargl at gcc dot gnu dot org  2008-07-26 01:18 ---

(In reply to comment #6)
> Kargl
> 
> Thanks again, this really helped me out
> 
> Mike
> 
> PS, I like the replica...
> 

The problem does not appear in 4.2.5 or 4.4.0.  I don't have
a 4.3.1 compiler installed, so can't tested.  I'm closing 
this as FIXED.

PS: Most people don't know about Trout Mask Replica.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/36929] [4.3/4.4 Regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-07-26 01:05 ---
emit_insn_before might work too, I don't know if the location marker here is
important or not ...


-- 


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

[Bug rtl-optimization/36929] [4.3/4.4 Regression] internal compiler error: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-26 01:03 ---
I think s/add_insn_before/emit_insn_before_noloc will work.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug fortran/36942] iostat and/or end= and Err= don't work in read statements, unformatted reads

[kyon at verizon dot net]

--- Comment #6 from kyon at verizon dot net  2008-07-26 00:10 ---
Subject: Re:  iostat and/or end= and Err= don't work in read
 statements, unformatted reads

Kargl

Thanks.  I'm now in the process of attempting to update my gcc 
collection to at least 4.3. 

If you can verify this will work, I'd appreciate it.  (I'm using fedora, 
and fc9 has 4.3).

If you can't, still thanks.  This at least means I'm not going 
completely bonkers.

### Ok, my email situation is so bad, I got the newer compilers 
installed and working, and 4.3.0-8, specifically the fc9 version, 
gcc-gfortran-4.3.0-8, is working like a champ.  This before this message 
actually made it off my machine.  ###

Thanks again, this really helped me out

Mike

PS, I like the replica...


kargl at gcc dot gnu dot org wrote:
> --- Comment #3 from kargl at gcc dot gnu dot org  2008-07-25 22:41 ---
> Update your ancient compiler.
>
> troutmask:sgk[211] gfc --version
> GNU Fortran (GCC) 4.2.5 20080702 (prerelease)
> troutmask:sgk[212] gfc -o z m.f
> troutmask:sgk[213] ./z
>1   0   0
> STOP ERror
>
> troutmask:sgk[214] gfc4x --version
> GNU Fortran (GCC) 4.4.0 20080611 (experimental)
> troutmask:sgk[215] gfc4x -o z m.f
> troutmask:sgk[216] ./z
>1   0   0
> STOP ERror
>
>
>   


-- 


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

[Bug c++/36943] New: Use of nested C++0x initializer list for non-aggregate rejected

[gcc-bugzilla at contacts dot eelis dot net]

C++0x-style initializer list support was recently added, but the following
valid code is rejected:

  struct p { p(int, int); };
  p a[] = { { 3, 2 } };

With -std=c++0x, the second line results in:

  error: braces around scalar initializer for type 'p'


-- 
   Summary: Use of nested C++0x initializer list for non-aggregate
rejected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c/36941] gcc does not reject invalid cast

[joseph at codesourcery dot com]

--- Comment #4 from joseph at codesourcery dot com  2008-07-25 22:59 ---
Subject: Re:  gcc does not reject invalid cast

On Fri, 25 Jul 2008, sabre at nondot dot org wrote:

> Though that does raise a question.  Does GCC normally emit errors for 
> undefined
> behavior?  I thought the policy was to insert runtime traps?  If so, doesn't
> the { x; } case qualify, or does it violate some other constraint?

What's valid for expressions of incomplete types - including whether the 
cases of undefined behavior here are undefined only at execution or 
undefined as a property of the program (the former being where traps are 
inserted, the latter being where diagnostics are OK) is exceedingly 
obscure.  We do have a bit of guidance in the form of DR 106 allowing the 
dereference of pointers to qualified void in certain cases (note that 
qualified void is an incomplete type other than void).  It doesn't help 
that neither C90 nor C99 got the definition of "lvalue" right.


-- 


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

[Bug fortran/36942] iostat and/or end= and Err= don't work in read statements, unformatted reads

[michael dot e dot olsen at nasa dot gov]

--- Comment #5 from michael dot e dot olsen at nasa dot gov  2008-07-25 
22:51 ---
Created an attachment (id=15964)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15964&action=view)
Version showing iostat isn't distinguishing either.

This version is a little more involved, and opens and closes the file to create
error and end conditions.  iostat allways returns 0 for normal cases, and -1
for either end or error conditions


-- 


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

[Bug fortran/36942] iostat and/or end= and Err= don't work in read statements, unformatted reads

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2008-07-25 22:45 ---
Your iostat code with the same compilers shows

troutmask:sgk[219] ./z
 ival(should indicate normal)   0
 ival(should indicate normal)   0
 ival(should indicate end)  -1
 File closed and then reopened for errors...
 ival(should indicate error)  17
STOP making sense
troutmask:sgk[220] gfc4x -o z n.f
troutmask:sgk[221] ./z
 ival(should indicate normal)   0
 ival(should indicate normal)   0
 ival(should indicate end)  -1
 File closed and then reopened for errors...
 ival(should indicate error)5016
STOP making sense


-- 


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

[Bug fortran/36942] iostat and/or end= and Err= don't work in read statements, unformatted reads

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2008-07-25 22:41 ---
Update your ancient compiler.

troutmask:sgk[211] gfc --version
GNU Fortran (GCC) 4.2.5 20080702 (prerelease)
troutmask:sgk[212] gfc -o z m.f
troutmask:sgk[213] ./z
   1   0   0
STOP ERror

troutmask:sgk[214] gfc4x --version
GNU Fortran (GCC) 4.4.0 20080611 (experimental)
troutmask:sgk[215] gfc4x -o z m.f
troutmask:sgk[216] ./z
   1   0   0
STOP ERror


-- 


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

[Bug fortran/36942] iostat and/or end= and Err= don't work in read statements, unformatted reads

[michael dot e dot olsen at nasa dot gov]

--- Comment #2 from michael dot e dot olsen at nasa dot gov  2008-07-25 
22:37 ---
Created an attachment (id=15963)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15963&action=view)
Version showing iostat isn't distinguishing either.

This version is a little more involved, and opens and closes the file to create
error and end conditions.  iostat allways returns 0 for normal cases, and -1
for either end or error conditions


-- 


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

[Bug fortran/36942] iostat and/or end= and Err= don't work in read statements, unformatted reads

[michael dot e dot olsen at nasa dot gov]

--- Comment #1 from michael dot e dot olsen at nasa dot gov  2008-07-25 
22:35 ---
Created an attachment (id=15962)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15962&action=view)
Coding to reproduce bug described

Didn't know I could add attachment.  I'll add one demonstrating that iostat has
the same behavior


-- 


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

[Bug c/36941] gcc does not reject invalid cast

[sabre at nondot dot org]

--- Comment #3 from sabre at nondot dot org  2008-07-25 22:31 ---
Though that does raise a question.  Does GCC normally emit errors for undefined
behavior?  I thought the policy was to insert runtime traps?  If so, doesn't
the { x; } case qualify, or does it violate some other constraint?


-- 


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

[Bug fortran/36942] New: iostat and/or end= and Err= don't work in read statements, unformatted reads

[michael dot e dot olsen at nasa dot gov]

Coding to detect end of file or read error just won't work, and I can't see a
work around.  Coding to differentiate between end of file and error condition
doesn't work, it all acts like an error.

I have a test code, included below, which creates a simple unformatted file
with two records.  The first record contains a single integer, and the second
record contains three integers.  

Once this test file is created, it is re-opened and read, attempting a read of
three integers, rather than 1 integer, on the first record. This should create
a error condition, and it should write out the stop error message stating so. 
Instead, it writes out the message for the END=100 label.  

Using IOSTAT doesn't differentiate between end= and err= conditions either, it
seems to return 0 for no problems, and -1 for anything else...

Code has been run on opteron, centrino, and itanium systems, all running linux
(fedora core 8 on the first two, last Suse)

!---Relevant Code follows
  integer ni, nj, nk
  ni = 1
  nj = 1
  nk = 1
  open(1,file='test.data',form='unformatted')
  write(1) ni
  write(1) ni,nj,nk
  close(1)
  ni = 0
  nj = 0
  nk = 0
  open(1,file='test.data',form='unformatted')
  read(1,err=10,end=100)ni,nj,nk
  write(*,*)ni, nj, nk
  stop 'No End, No ERror'
   10 continue
  write(*,*)ni, nj, nk
  stop 'ERror'
  100 continue
  write(*,*)ni, nj, nk
  stop 'End'
  end
!---End of Code 


-- 
   Summary: iostat and/or end= and Err= don't work in read
statements, unformatted reads
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot e dot olsen at nasa dot gov


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

[Bug c/36941] gcc does not reject invalid cast

[sabre at nondot dot org]

--- Comment #2 from sabre at nondot dot org  2008-07-25 22:30 ---
'If the lvalue has an incomplete type and does not have array type, the
behavior is 
undefined.'

QoI


-- 


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

[Bug c/36941] gcc does not reject invalid cast

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2008-07-25 22:29 ---
Subject: Re:   New: gcc does not reject invalid cast

On Fri, 25 Jul 2008, sabre at nondot dot org wrote:

> GCC accepts:
> extern struct S x;
> void foo() { (void)x; }

What constraint do you think this violates, or are you just reporting a 
QoI issue for not diagnosing undefined behavior?


-- 


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

[Bug c/36941] New: gcc does not reject invalid cast

[sabre at nondot dot org]

GCC accepts:
extern struct S x;
void foo() { (void)x; }

But correctly rejects:

extern struct S x;
void foo() { x; }

Comeau rejects both in c99 mode.


-- 
   Summary: gcc does not reject invalid cast
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org


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

[Bug fortran/36934] [4.4 regression] Spurious "ambiguous reference to...ERROR"/ICE

[tkoenig at netcologne dot de]

--- Comment #7 from tkoenig at netcologne dot de  2008-07-25 21:58 ---
Subject: Re:  [4.4 regression] Spurious "ambiguous
reference to...ERROR"/ICE

On Fri, 2008-07-25 at 21:44 +, burnus at gcc dot gnu dot org wrote:

> I think it was my mistake. I assume Philip used my x86-64-linux nightly build.
> I found out that I applied Daniel's finalizer patch to the wrong tree.

So, resolve this as fixed and add a test case?

Thomas


-- 


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

[Bug fortran/36934] [4.4 regression] Spurious "ambiguous reference to...ERROR"/ICE

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2008-07-25 21:44 ---
> > New status, I did update my other tree (unpatched) to the latest SVN, and
> > couldn't reproduce the problem there.
> I tried the same with an unpatched tree.

I think it was my mistake. I assume Philip used my x86-64-linux nightly build.
I found out that I applied Daniel's finalizer patch to the wrong tree.

That explains why it fails with the finalize patch but not with the (clean)
trunk. However, knowing this failure is useful nonetheless as one can then iron
out the problem before the finalizer merge.


-- 


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

[Bug rtl-optimization/36929] [4.3/4.4 Regression] internal compiler error: Segmentation fault

[schwab at suse dot de]

--- Comment #2 from schwab at suse dot de  2008-07-25 21:33 ---
The bug is in dse.c:replace_inc_dec:

add_insn_before (data->insn, 
 gen_rtx_SET (Pmode, r1, 
  gen_rtx_PLUS (Pmode, r1, c)),
 NULL);

This does not make any sense: the rtx to be added must satisfy INSN_P, LABEL_P,
BARRIER_P or NOTE_P, and the first two arguments are swapped.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 CC||zadeck at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|target  |rtl-optimization
 Ever Confirmed|0   |1
 GCC target triplet|m68k-unknown-linux-gnu  |m68k-*-*
   Last reconfirmed|-00-00 00:00:00 |2008-07-25 21:33:41
   date||


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

[Bug fortran/36934] [4.4 regression] Spurious "ambiguous reference to...ERROR"/ICE

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2008-07-25 21:21 ---
(In reply to comment #4)
> New status, I did update my other tree (unpatched) to the latest SVN, and
> couldn't reproduce the problem there.

I tried the same with an unpatched tree.

Philip: Could you post the module files fred1.mod and fred2.mod
that you got from the compilation?

If all fails, we can always add the example as a test case.  We'll
then see a regression if the problem re-surfaces.


-- 


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

[Bug ada/36940] New: Compiler error on many ACATS tests on bfin target

[joel at gcc dot gnu dot org]

There were 191 tests which failed to build.  There were 190 lines with 
stor-layout.c:258 on them.  So this error is responsible for almost all 
of the ACATS build failures on bfin.

bfin-rtems4.9-gcc -c -fstack-check -O -gnatws -O2
-I/home/joel/work-gnat/svn/gcc/gcc/testsuite/ada/acats/work-eZKit533/support
a87b59a.adb

I tried this at various optimization levels and it doesn't matter.

+===GNAT BUG DETECTED==+
| 4.4.0 20080722 (experimental) [trunk revision 138063] (bfin-unknown-rtems4.9)
GCC error:|
| in int_mode_for_mode, at stor-layout.c:258   |
| Error detected around a87b59a.adb:33 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

a87b59a.adb
/home/joel/work-gnat/svn/gcc/gcc/testsuite/ada/acats/work-eZKit533/support/report.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424
End of compilation


-- 
   Summary: Compiler error on many ACATS tests on bfin target
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: bfin-rtems4.9


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

[Bug ada/36939] Build Failure Ada SH2e

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2008-07-25 20:53 ---
Subject: Re:   New: Build Failure Ada SH2e

On Fri, 25 Jul 2008, joel at gcc dot gnu dot org wrote:

> According to comments in sh.h, SH2e only has single precision floating point
> and fails during build of SH2e variant. 

I suppose an unfortunate choice of ABI is set in stone here?  You can 
perfectly well have hardware with only single-precision floating-point and 
still have double (and whatever Ada types correspond to it) being 64 bit.  
On Power, E500v1 does that, ABI-compatibly with E500v2 and soft-float.


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

--- Comment #4 from laurent at guerby dot net  2008-07-25 20:46 ---
Only one ACATS test activate this package to my knowledge, so the change is
safe for compiling purposes :).


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-07-25 20:35 ---
> This tells us s-scaval.adb assumes long_float is at least 64 bits, but it 
> seems to be 32 bits for sh target. 

Just to precise -- only on this multilib variant.  I am pretty sure other
SH models have double precision float.  

> You can replace the body of the procedure Initialize in s-scaval.adb by an
> empty body, it will deactivate some GNAT specific features but allows for
> compilation on all targets:

Do you mean GNAT specific or Ada specified?  This code is where variables 
get their default values.  It looks dangerous to disable this for what
could happen on other targets.

> Only long_long_float seems to be 64 bits on sh and this also breaks another
> assumption made a few lines below, that is that we are on ... x86 :)

Yes that would be a very poor assumption in this case.


-- 


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[hjl at gcc dot gnu dot org]

--- Comment #10 from hjl at gcc dot gnu dot org  2008-07-25 20:31 ---
Subject: Bug 36926

Author: hjl
Date: Fri Jul 25 20:30:35 2008
New Revision: 138148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138148
Log:
2008-07-25  Martin Jambor  <[EMAIL PROTECTED]>

PR tree-optimization/36926
* ipa-prop.c (ipa_analyze_call_uses): Call
ipa_is_ssa_with_stmt_def instead of SSA_NAME_IS_DEFAULT_DEF.

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


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2008-07-25 20:04 ---
You can replace the body of the procedure Initialize in s-scaval.adb by an
empty body, it will deactivate some GNAT specific features but allows for
compilation on all targets:

   procedure Initialize (Mode1 : Character; Mode2 : Character) is
   begin
  null;
   end Initialize;


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2008-07-25 19:52 ---
  AFloat : constant Boolean :=
 Long_Float'Size = 48 and Long_Long_Float'Size = 48;
  --  Set True if we are on an AAMP with 48-bit extended floating point

  type ByteLF is array (0 .. 7 - 2 * Boolean'Pos (AFloat)) of Byte1;

  IV_Ilf : aliased ByteLF;-- Initialize long float

  for IV_Ilf'Address use IS_Ilf'Address;

   IS_Ilf : aliased Long_Float  := 0.0;  -- Initialize long float

This tells us s-scaval.adb assumes long_float is at least 64 bits, but it seems
to be 32 bits for sh target. 

Only long_long_float seems to be 64 bits on sh and this also breaks another
assumption made a few lines below, that is that we are on ... x86 :)

 EFloat : constant Boolean := Long_Long_Float'Size > Long_Float'Size;
  --  Set True if we are on an x86 with 96-bit floats for extended


-- 


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

[Bug ada/36939] New: Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

According to comments in sh.h, SH2e only has single precision floating point
and fails during build of SH2e variant. 

/home/joel/work-gnat/svn/b-gcc2-sh/./gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc2-sh/./gcc/ -nostdinc
-B/home/joel/work-gnat/svn/b-gcc2-sh/sh-rtems4.9/newlib/ -isystem
/home/joel/work-gnat/svn/b-gcc2-sh/sh-rtems4.9/newlib/targ-include -isystem
/home/joel/work-gnat/svn/gcc/newlib/libc/include
-B/home/joel/work-gnat/svn//install/sh-rtems4.9/bin/
-B/home/joel/work-gnat/svn//install/sh-rtems4.9/lib/ -isystem
/home/joel/work-gnat/svn//install/sh-rtems4.9/include -isystem
/home/joel/work-gnat/svn//install/sh-rtems4.9/sys-include -c -g -O2 -m2e 
-W -Wall -gnatpg -m2e  s-scaval.adb -o s-scaval.o
s-scaval.adb:105:07: warning: size for overlaid object is too small
s-scaval.adb:105:07: warning: size of "IV_Ilf" is 64
s-scaval.adb:105:07: warning: size of "IS_Ilf" is 32
s-scaval.adb:106:07: warning: size for overlaid object is too small
s-scaval.adb:106:07: warning: size of "IV_Ill" is 96
s-scaval.adb:106:07: warning: size of "IS_Ill" is 64
make[6]: *** [s-scaval.o] Error 1
make[6]: *** Waiting for unfinished jobs


-- 
   Summary: Build Failure Ada SH2e
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh-rtems4.9


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

[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault

[andreast at gcc dot gnu dot org]

--- Comment #19 from andreast at gcc dot gnu dot org  2008-07-25 18:30 
---
Fyi, this seems resloved on the tuples branch. Tested on various darwin
combinations and on i686-linux.


-- 


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

[Bug fortran/36934] [4.4 regression] Spurious "ambiguous reference to...ERROR"/ICE

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2008-07-25 18:28 ---
New status, I did update my other tree (unpatched) to the latest SVN, and
couldn't reproduce the problem there.  Maybe I messed something up or the
problem occurs not "unconditionally"...  With the patched finalizer-tree, I had
this error, with unpatched trees I'm so far not able to reproduce it.  But I'll
give some further experiments to that one.


-- 


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

[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-07-25 18:13 ---
(In reply to comment #5)
> > Does revision 138075 include a testcase for this?
> 
> No, but I was trying to explain what the motativation for the line was.
> 

I added 2 tesstcases in my patch:

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02031.html

They seem to work fine. Did I miss something?


-- 


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

[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove

[gnu at the-meissners dot org]

--- Comment #5 from gnu at the-meissners dot org  2008-07-25 18:08 ---
Subject: Re:  [4.4 Regression]: Revision 138075 breaks
cmove

On Fri, Jul 25, 2008 at 05:15:17PM -, hjl dot tools at gmail dot com wrote:
> 
> 
> --- Comment #3 from hjl dot tools at gmail dot com  2008-07-25 17:15 
> ---
> (In reply to comment #2)
> >
> > However, that would break using attribute((option("arch=i386"))) to turn off
> > cmoves.  I suspect the patch needs to be reworked.
> > 
> 
> Does revision 138075 include a testcase for this?

No, but I was trying to explain what the motativation for the line was.


-- 


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

[Bug ada/36937] Compiler error on ACATS cxg1004

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2008-07-25 18:01 ---

Compiler error at -O2 but not with -O or -O1

Removing -fstack-check has no effect.  So "-O2"  is the shortest set of options
that fail.  -O1 works.


-- 


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

[Bug ada/36937] Compiler error on ACATS cxg1004

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-07-25 17:58 ---
Didn't cut and paste exception message.  Here it is.

raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424


-- 


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

[Bug ada/36937] Compiler error on ACATS cxg1004

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2008-07-25 17:57 ---
Created an attachment (id=15961)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15961&action=view)
Concatenated source code per bug box request


-- 


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

[Bug middle-end/36938] New: [4.4 Regression] Revision 138140 caused FAIL: gcc.dg/20040206-1.c

[hjl dot tools at gmail dot com]

On Linux/x86, revision 138140:

http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00852.html

caused

FAIL: gcc.dg/20040206-1.c  (test for warnings, line 10)
FAIL: gcc.dg/20040206-1.c (test for excess errors)


-- 
   Summary: [4.4 Regression] Revision 138140 caused FAIL:
gcc.dg/20040206-1.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug ada/36937] New: Compiler error on ACATS cxg1004

[joel at gcc dot gnu dot org]

arm-rtems4.9-gcc -c -fstack-check -O -gnatws -O2
-I/home/joel/work-gnat/svn/gcc/gcc/testsuite/ada/acats/work-edb7312/support
cxg1004.adb
+===GNAT BUG DETECTED==+
| 4.4.0 20080722 (experimental) [trunk revision 138063] (arm-unknown-rtems4.9)
GCC error:|
| in fold_convert, at fold-const.c:2528|
| Error detected around cxg1004.adb:57 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+


-- 
   Summary: Compiler error on ACATS cxg1004
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-rtems4.9


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

[Bug tree-optimization/9079] [tree-ssa] Inline constant function pointers

[jamborm at gcc dot gnu dot org]

--- Comment #19 from jamborm at gcc dot gnu dot org  2008-07-25 17:51 
---
As of revision 138092 we are handling this much better.

The example in bug description gets inlined at -O2 even with
-fno-early-inlining.

The example  in comment #10  does not work  as expected yet.   The new
edge is discovered but  the always_inline attribute is disregarded and
the inlined does  not decide to inline  it on its own.  I  will try to
fix this but it should be  noted that few guarantees can be made about
indirect  calls  to always_inline  functions  and about  always_inline
functions which have their addresses taken in general.

As far  as the  third example  in comment #11  is concerned,  the only
problem is  loading the  target function from  the array.   The loaded
value is not  recognized to be constant early  enough to be considered
for inlining.  That is really a separate issue though, quite different
from the one originally described.  I  will have a look at what we can
do earlier but I will close the bug if this is the only outstanding
issue and I don't see an easy fix.


-- 


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

[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-07-25 17:45 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02031.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||07/msg02031.html


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

[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-07-25 17:15 ---
(In reply to comment #2)
>
> However, that would break using attribute((option("arch=i386"))) to turn off
> cmoves.  I suspect the patch needs to be reworked.
> 

Does revision 138075 include a testcase for this?


-- 


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

[Bug fortran/36934] [4.4 regression] Spurious "ambiguous reference to...ERROR"/ICE

[domob at gcc dot gnu dot org]

--- Comment #3 from domob at gcc dot gnu dot org  2008-07-25 17:13 ---
Hm... The tree I used for this check-in seems not to produce the crash, but my
current working-copy for finalization (updated last yesterday evening) shows it
(GNU/Linux-x86-32).

I will try to find out more on this one, as my patch looks really as if it
could be connected.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2008-07-25 17:11 ---
(In reply to comment #7)
> 
> 2008-07-25  Martin Jambor  <[EMAIL PROTECTED]>
> 
> PR 36926
> * ipa-prop.c (ipa_analyze_call_uses): Call
> ipa_is_ssa_with_stmt_def instead of SSA_NAME_IS_DEFAULT_DEF.
> 

Yes, it fixed 483.xalancbmk.


-- 


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

[Bug fortran/36934] [4.4 regression] Spurious "ambiguous reference to...ERROR"/ICE

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-07-25 16:55 ---
Can't confirm right now, but this might be a suspect (at
least it is recent enough):

http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00833.html


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Spurious "ambiguous |[4.4 regression] Spurious
   |reference to...ERROR"/ICE   |"ambiguous reference
   ||to...ERROR"/ICE
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[jamborm at gcc dot gnu dot org]

--- Comment #8 from jamborm at gcc dot gnu dot org  2008-07-25 16:45 ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02014.html

Tuples version: http://gcc.gnu.org/ml/gcc-patches/2008-07/msg02017.html


-- 


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

[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove

[gnu at the-meissners dot org]

--- Comment #2 from gnu at the-meissners dot org  2008-07-25 16:45 ---
Subject: Re:  [4.4 Regression]: Revision 138075 breaks
cmove

On Fri, Jul 25, 2008 at 03:36:51PM -, hjl dot tools at gmail dot com wrote:
> 
> 
> --- Comment #1 from hjl dot tools at gmail dot com  2008-07-25 15:36 
> ---
> I believe this bug was introduced by
> 
> @@ -2743,11 +3118,13 @@ override_options (void)
>&& !(target_flags & MASK_ACCUMULATE_OUTGOING_ARGS))
>  {
>if (target_flags_explicit & MASK_ACCUMULATE_OUTGOING_ARGS)
> -   warning (0, "stack probing requires -maccumulate-outgoing-args "
> -"for correctness");
> +   warning (0, "stack probing requires %saccumulate-outgoing-args%s "
> +"for correctness", prefix, suffix);
>target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
>  }
> 
> +  TARGET_CMOVE = 0;
> +
>/* For sane SSE instruction set generation we need fcomi instruction.
>   It is safe to enable all CMOVE instructions.  */
>if (TARGET_SSE)

However, that would break using attribute((option("arch=i386"))) to turn off
cmoves.  I suspect the patch needs to be reworked.



-- 


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

[Bug bootstrap/36918] [4.4 regression] Bootstrap failure on sparc: assertion failure in options.c

[andreast at gcc dot gnu dot org]

--- Comment #7 from andreast at gcc dot gnu dot org  2008-07-25 15:59 
---
Subject: Bug 36918

Author: andreast
Date: Fri Jul 25 15:59:12 2008
New Revision: 138145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138145
Log:
2008-07-25  Andreas Tobler  <[EMAIL PROTECTED]>

PR bootstrap/36918
* config/sparc/sparc.h (DEFAULT_PCC_STRUCT_RETURN): Define
DEFAULT_PCC_STRUCT_RETURN to 127.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.h


-- 


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

[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |4.4.0


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

[Bug target/36936] [4.4 Regression]: Revision 138075 breaks cmove

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-07-25 15:36 ---
I believe this bug was introduced by

@@ -2743,11 +3118,13 @@ override_options (void)
   && !(target_flags & MASK_ACCUMULATE_OUTGOING_ARGS))
 {
   if (target_flags_explicit & MASK_ACCUMULATE_OUTGOING_ARGS)
-   warning (0, "stack probing requires -maccumulate-outgoing-args "
-"for correctness");
+   warning (0, "stack probing requires %saccumulate-outgoing-args%s "
+"for correctness", prefix, suffix);
   target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
 }

+  TARGET_CMOVE = 0;
+
   /* For sane SSE instruction set generation we need fcomi instruction.
  It is safe to enable all CMOVE instructions.  */
   if (TARGET_SSE)


-- 


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

[Bug target/36936] New: [4.4 Regression]: Revision 138075 breaks cmove

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] gcc]$ cat /tmp/c.c
int
foo (int x)
{
if (x < 0)
 x = 1;
return x;
}
[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -m32 -S -O2 /tmp/c.c -march=i686
[EMAIL PROTECTED] gcc]$ cat c.s
.file   "c.c"
.text
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
pushl   %ebp
movl%esp, %ebp
movl8(%ebp), %eax
testl   %eax, %eax
js  .L5
popl%ebp
ret
.p2align 4,,7
.p2align 3
.L5:
movl$1, %eax
popl%ebp
ret
.size   foo, .-foo


-- 
   Summary: [4.4 Regression]: Revision 138075 breaks cmove
   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: i686-pc-linux-gnu


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

[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables

[andry at inbox dot ru]

--- Comment #14 from andry at inbox dot ru  2008-07-25 15:03 ---
Sorry, i think this is different error, not dependent on root folder of Mingw
system. I thinks happend because PATH in Mingw system has "/mingw/bin" part,
which brokes build. I was removed it and additionally add "/mingw" mount path
and error disappeared.


-- 


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

[Bug c++/36921] comparsion does not have mathematical meaning is not correct

[deba at inf dot elte dot hu]

--- Comment #4 from deba at inf dot elte dot hu  2008-07-25 14:43 ---
(In reply to comment #3)
> What Andrew means by "example" is a short, self-contained, compilable testcase
> that shows the undesired behaviour.
> 

struct A {};
A operator<(A, A) { return A(); }

int main() {
A() < A() < A(); // should not emit warning
1 < 2 < 3; // should emit warning
return 0;
}


-- 


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

[Bug c++/36921] comparsion does not have mathematical meaning is not correct

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-07-25 14:34 ---
What Andrew means by "example" is a short, self-contained, compilable testcase
that shows the undesired behaviour.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug fortran/36935] unneeded temporary

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-07-25 14:26 ---
(In reply to comment #1)
> Reads similar to http://gcc.gnu.org/ml/fortran/2008-07/msg00163.html
> 
> PaulT wrote:
> >  pt = point((/ x, y, z /))
> >1
> > Warning: Creating array temporary at (1)
> 
> This will always occur where an array actual argument is not a
> contiguous section of a variable.
> 

It is similar, but I believe Paul might have misread your example. His comment
would but right if point were a function call, but it is not. I believe a temp
shouldn't be created in your example.


-- 


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

[Bug fortran/36935] unneeded temporary

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-07-25 14:18 ---
Reads similar to http://gcc.gnu.org/ml/fortran/2008-07/msg00163.html

PaulT wrote:
>  pt = point((/ x, y, z /))
>1
> Warning: Creating array temporary at (1)

This will always occur where an array actual argument is not a
contiguous section of a variable.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug fortran/36934] Spurious "ambiguous reference to...ERROR"/ICE

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-07-25 14:16 ---
Can not reproduce this on either i686-pc-linux-gnu (20080722) or
x86_64-unknown-linux-gnu (20080724).


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[jamborm at gcc dot gnu dot org]

--- Comment #7 from jamborm at gcc dot gnu dot org  2008-07-25 14:09 ---
OK, I think I have it.  It was a stupid mistake on my side.  The
following patch seems to fix it:

Subject: Fix PR 36926

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

PR 36926
* ipa-prop.c (ipa_analyze_call_uses): Call
ipa_is_ssa_with_stmt_def instead of SSA_NAME_IS_DEFAULT_DEF.


Index: iinln/gcc/ipa-prop.c
===
--- iinln.orig/gcc/ipa-prop.c
+++ iinln/gcc/ipa-prop.c
@@ -741,7 +741,7 @@ ipa_analyze_call_uses (struct ipa_node_p
  pointer that is a parameter to this function. */
   n1 = PHI_ARG_DEF (def, 0);
   n2 = PHI_ARG_DEF (def, 1);
-  if (SSA_NAME_IS_DEFAULT_DEF (n1) || SSA_NAME_IS_DEFAULT_DEF (n2))
+  if (!ipa_is_ssa_with_stmt_def (n1) || !ipa_is_ssa_with_stmt_def (n2))
 return;
   d1 = SSA_NAME_DEF_STMT (n1);
   d2 = SSA_NAME_DEF_STMT (n2);


-- 


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[doko at ubuntu dot com]

--- Comment #11 from doko at ubuntu dot com  2008-07-25 13:54 ---
the suggested change fixes the OpenJDK build.


-- 


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

[Bug fortran/36935] New: unneeded temporary

[jv244 at cam dot ac dot uk]

integer :: a(3)
a=(/i,j,k/)
END


-- 
   Summary: unneeded temporary
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug fortran/36933] unneeded temporary

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-07-25 13:06 ---
Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-25 13:06:45
   date||


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

[Bug fortran/36932] unneeded temporary (2x)

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-07-25 13:05 ---
Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-25 13:05:18
   date||


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

[Bug fortran/36931] unneeded temporary

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-07-25 13:04 ---
Confirmed.

I knew I was opening a can of worms with that option :-)


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-25 13:04:23
   date||


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

[Bug tree-optimization/36917] [4.3 regression] miscompilation with -O2 and r136501

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-07-25 12:14 
---
I belive this is just INVALID.  The code seems to do lots of things with
this enum Cell, but the C++ compiler is allowed to just allocate 1 bit of
storage for it.

Maybe changing the Cell declaration to

enum Cell { Cell_0, Cell_max = UINT_MAX }

fixes the issue.

See 7.2/6 for the standard wording.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug fortran/36934] New: Spurious "ambiguous reference to...ERROR"/ICE

[pmason at ricardo dot com]

Get following error message/crash when compiling with latest gfortran:

<<<<<<<<<<<<<<<<<<<<<
Error: Name 'allocated' at (1) is an ambiguous reference to 'allocated' from
module 'fred1'
f951: 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.
>>>>>>>>>>>>>>>>>>>>>>>>

Using version 4.4.0 20080725 (experimental) of gfortran on Suse10 (x86-64).

Code that causes problem:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
module fred1
real, allocatable :: default_clocks(:)
end module fred1

module fred2
real, allocatable :: locks(:)
end module fred2

program fred
use fred1
use fred2
end program fred
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Compiled as:

gfortran -c test.f90


-- 
   Summary: Spurious "ambiguous reference to...ERROR"/ICE
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pmason at ricardo 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=36934

[Bug c/36929] [4.3/4.4 Regression] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.2


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

[Bug fortran/36933] New: unneeded temporary

[jv244 at cam dot ac dot uk]

another unneeded temporary (since a has neither a pointer nor a target
attribute)

MODULE M1
  IMPLICIT NONE
  TYPE cell_type
 REAL :: h(3,3)
  END TYPE
CONTAINS
  SUBROUTINE S1(cell)
 TYPE(cell_type), POINTER :: cell
 REAL :: a(3),b(3)
 a=MATMUL(cell%h,b)
  END SUBROUTINE S1
END MODULE M1


-- 
   Summary: unneeded temporary
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug fortran/36932] New: unneeded temporary (2x)

[jv244 at cam dot ac dot uk]

The line 'a=pbc(p(i)%r)' warns twice about an array temporary, but none should
be needed:

MODULE M1
  IMPLICIT NONE
  TYPE particle
   REAL :: r(3)
  END TYPE
CONTAINS
  SUBROUTINE S1()
 TYPE(particle), POINTER, DIMENSION(:) :: p
 REAL :: a(3)
 INTEGER :: i
 a=pbc(p(i)%r)
  END SUBROUTINE S1
  FUNCTION pbc(a)
 REAL :: a(3)
 REAL :: pbc(3)
 pbc=a
  END FUNCTION
END MODULE M1


-- 
   Summary: unneeded temporary (2x)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug fortran/36931] New: unneeded temporary

[jv244 at cam dot ac dot uk]

-Warray-temporaries indicates a temporary here:

MODULE M1
CONTAINS
  SUBROUTINE S1()
 REAL :: a(3),b(3,3),c(3)
 a=MATMUL(b,c)/2
  END SUBROUTINE S1
END MODULE M1

but it could be avoided as in:

MODULE M1
CONTAINS
  SUBROUTINE S1()
 REAL :: a(3),b(3,3),c(3)
 a=MATMUL(b,c)
 a=a/2
  END SUBROUTINE S1
END MODULE M1


-- 
   Summary: unneeded temporary
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk


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

[Bug c++/36921] comparsion does not have mathematical meaning is not correct

[deba at inf dot elte dot hu]

--- Comment #2 from deba at inf dot elte dot hu  2008-07-25 10:24 ---
(In reply to comment #1)
> Example?
> 

In the LEMON graph library  (http://lemon.cs.elte.hu/) there is an LP solver
interface. The LP constraints could be added like the next formulation:
lp.addRow((double) <= (Lp::Expr) <= (double));
For example:
Lp::Col x1, x2, x3;
lp.addRow(2 <= 2 * x1 + 3 * x2 - 2 * x3 <= 8);
Because the C++ allows overriding every operator, it looks like a good solution
for define range constraints. However, if the -Wparentheses or -Wall is
defined, it emits warnings. For the C language, the warning is a proper
behavior, but the C++ has boolean type, so rather the bool-numeric comparisons
should be warned.


-- 


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

[Bug ada/36930] "GNAT BUG DETECTED" while creating object on storage pool

[timo dot warns at informatik dot uni-oldenburg dot de]

--- Comment #1 from timo dot warns at informatik dot uni-oldenburg dot de  
2008-07-25 10:22 ---
Created an attachment (id=15960)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15960&action=view)
dummy.adb


-- 


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

[Bug ada/36930] New: "GNAT BUG DETECTED" while creating object on storage pool

[timo dot warns at informatik dot uni-oldenburg dot de]

gnatgcc -v -c dummy.adb

Ziel: i686-pc-linux-gnu
Konfiguriert mit:
/var/tmp/portage/dev-lang/gnat-gcc-4.2.2/work/gcc-4.2.2/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.2
--includedir=/usr/lib/gnat-gcc/i686-pc-linux-gnu/4.2/include
--libdir=/usr/lib/gnat-gcc/i686-pc-linux-gnu/4.2
--libexecdir=/usr/libexec/gnat-gcc/i686-pc-linux-gnu/4.2
--datadir=/usr/share/gnat-gcc-data/i686-pc-linux-gnu/4.2
--mandir=/usr/share/gnat-gcc-data/i686-pc-linux-gnu/4.2/man
--infodir=/usr/share/gnat-gcc-data/i686-pc-linux-gnu/4.2/info
--program-prefix=gnat --enable-languages=c,ada --enable-libada --with-gcc
--enable-threads=posix --enable-shared --with-system-zlib
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --disable-libunwind-exceptions
Thread-Modell: posix
gcc-Version 4.2.2
 gnat1 -quiet -dumpbase dummy.adb -mtune=generic dummy.adb -o
/home/timow/tmp/ccbjLW3d.s
+===GNAT BUG DETECTED==+
| 4.2.2 (i686-pc-linux-gnu) Assert_Failure namet.adb:680   |
| Error detected at dummy.adb:11:17|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases, 
so please double check that the problem can still 
be reproduced with the set of files listed.

dummy.adb

compilation abandoned


-- 
   Summary: "GNAT BUG DETECTED" while creating object on storage
pool
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timo dot warns at informatik dot uni-oldenburg dot de
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/36132] _gfortran_internal_pack on optional arguments

[jv244 at cam dot ac dot uk]

--- Comment #9 from jv244 at cam dot ac dot uk  2008-07-25 10:20 ---
Any plans to look into a fix for this for 4.3.X ?  This is variant of the
testcase that causes a runtime abort (trunk on x86_64-unknown-linux-gnu):

> gfortran -O2 test.f90 ; ./a.out
Operating system error: Cannot allocate memory
Memory allocation failed

> cat test.f90
MODULE M1
  INTEGER, PARAMETER :: dp=KIND(0.0D0)
CONTAINS
  SUBROUTINE S0()
REAL(dp) :: a(5,9,3,5)
CALL S1(a)
  END SUBROUTINE
  SUBROUTINE S1(a)
 REAL(dp), DIMENSION(45), INTENT(OUT), &
  OPTIONAL   :: a
  IF (PRESENT(a)) CALL RANDOM_NUMBER(a)
  END SUBROUTINE S1
  SUBROUTINE S2(a)
  REAL(dp), DIMENSION(:, :), INTENT(OUT), &
  OPTIONAL   :: a
  CALL S1(a)
  END SUBROUTINE
END MODULE M1
USE M1

CALL S0()
CALL S2()
END


-- 


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

[Bug c/36929] [4.3/4.4 Regression] internal compiler error: Segmentation fault

[bunk at stusta dot de]

--- Comment #1 from bunk at stusta dot de  2008-07-25 09:58 ---
Created an attachment (id=15959)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15959&action=view)
route.i


-- 


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

[Bug c/36929] New: [4.3/4.4 Regression] internal compiler error: Segmentation fault

[bunk at stusta dot de]

$ m68k-linux-gcc -O2 -m5200 route.i
/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/route.c: In function
'ipv4_sysctl_rtcache_flush':
/home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/route.c:2896: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$


-- 
   Summary: [4.3/4.4 Regression] internal compiler error:
Segmentation fault
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC target triplet: m68k-unknown-linux-gnu


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

[Bug target/36919] [4.4 regression] Bootstrap failure on IRIX 6.5: unrecognizable insn in errors.c

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |target
   Keywords||build
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/36926] [4.4 Regression] Revision 138092 breaks building of xalancbmk

[jamborm at gcc dot gnu dot org]

--- Comment #6 from jamborm at gcc dot gnu dot org  2008-07-25 08:57 ---
I will look at it straight away.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-25 08:57:42
   date||


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

[Bug fortran/36915] Unneccessary array temporary for same_array_ptr = const * same_array_ptr

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-07-25 08:43 ---
See also PR 36928 (interleaved assignment, where also an unneeded temporary is
created).


-- 


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

[Bug fortran/36928] array temporary for interleaving assignment

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-07-25 08:42 ---
See also PR 36915. This is one of the items where the middle-end array
expressions would help (see links in PR 36915). The ME array expr. support is
planned for 4.5.


-- 


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

[Bug fortran/29572] Bounds check should check size of array: d(1:1,1:1) = a(1:4,1:4)

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-07-25 08:15 ---
This works now, with the fixes for matmul bounds checks
(PR 36341):

$ cat mat.f90
program mat
  implicit none
  complex, allocatable :: a(:,:),b(:,:)
  complex  :: d(1,1)
  allocate(a(4,1),b(4,1))
  a = cmplx(0.5,2.0)
  b = cmplx(2.0,0.5)
  d = matmul(a,transpose(b))
  deallocate(a,b)
end program mat
$ gfortran -fbounds-check mat.f90
$ ./a.out
Fortran runtime error: Incorrect extent in return array in MATMUL intrinsic for
dimension 1: is 1, should be 4
$ cat mat-2.f90
program mat
  implicit none
  complex, allocatable :: a(:,:),b(:,:)
  complex  :: d(1,1)
  allocate(a(4,1),b(4,1))
  a = cmplx(0.5,2.0)
  b = cmplx(2.0,0.5)
  d = matmul(a,b)
  deallocate(a,b)
end program mat
$ gfortran -fbounds-check mat-2.f90
$ ./a.out
Fortran runtime error: Incorrect extent in return array in MATMUL intrinsic for
dimension 1: is 1, should be 4

The case of user-defined functions also works:

$ cat f.f90
module a
contains
  function f(x)
real, intent(in) :: x
real, dimension(3,3) :: f
f = x
  end function f
end module a

program main
  use a
  real, dimension(2,2) :: b
  b = f(1.0)
end program main
$ gfortran f.f90
f.f90:13.3:

  b = f(1.0)
  1
Error: Different shape for array assignment at (1) on dimension 1 (2 and 3)

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

[dberlin at dberlin dot org]

--- Comment #23 from dberlin at gcc dot gnu dot org  2008-07-25 08:11 
---
Subject: Re:  [4.4 Regression] I/Os hang at rev. 137631 on darwin9

The first.
For various reasons, get_external_unit in io/unit.c was being miscompiled.


On Fri, Jul 25, 2008 at 12:26 AM, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #21 from dominiq at lps dot ens dot fr  2008-07-25 07:26 
> ---
>> Yes
>
> To the first or the second question? If it is to the first, would it be
> possible to document what was going on?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
>
> --- 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=36806

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

[rguenther at suse dot de]

--- Comment #22 from rguenther at suse dot de  2008-07-25 08:11 ---
Subject: Re:  [4.4 Regression] I/Os hang at rev. 137631 on
 darwin9

On Fri, 25 Jul 2008, dominiq at lps dot ens dot fr wrote:

> --- Comment #21 from dominiq at lps dot ens dot fr  2008-07-25 07:26 
> ---
> > Yes
> 
> To the first or the second question? If it is to the first, would it be
> possible to document what was going on?

It's just no longer happening.  While there were fixes for bugs we
understood AFAIK nobody really analyzed this particular PR.

Richard.


-- 


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

[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.

[rakdver at gcc dot gnu dot org]

--- Comment #4 from rakdver at gcc dot gnu dot org  2008-07-25 07:56 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Also IV-opts is messing up anyways, it should have done out+1 as the base
> > instead of out, blah.
> 
> Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 .

Can we close this bug, then, or is there some other problem reported in this
testcase?  As far as I can tell, predictive commoning does not introduce any
new sign extensions (it does not eliminate any, either, but that is not its
job).


-- 


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

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

[dominiq at lps dot ens dot fr]

--- Comment #21 from dominiq at lps dot ens dot fr  2008-07-25 07:26 ---
> Yes

To the first or the second question? If it is to the first, would it be
possible to document what was going on?


-- 


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

[Bug target/36806] [4.4 Regression] I/Os hang at rev. 137631 on darwin9

[dberlin at dberlin dot org]

--- Comment #20 from dberlin at gcc dot gnu dot org  2008-07-25 07:11 
---
Subject: Re:  [4.4 Regression] I/Os hang at rev. 137631 on darwin9

Yes.


On Thu, Jul 24, 2008 at 11:56 PM, dominiq at lps dot ens dot fr
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #19 from dominiq at lps dot ens dot fr  2008-07-25 06:56 
> ---
>> I confirm that i686-apple-darwin on tuples branch does _not_ hang in these 
>> test cases
>
> Is this a real fix, i.e., the cause(s) of the hanging has(ve) been understood
> and fixed? or does it just happen that the hanging is no longer there?
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
>
> --- 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=36806