[Bug c/36024] Incorrect function name in linking error

[ashutosh dot nema at nechclst dot in]

--- Comment #3 from ashutosh dot nema at nechclst dot in  2008-04-24 06:55 
---
Hi Richard,
I agree because its a linking issue
but the suggestion preposed by you is not working 
"" -Wl,--no-demangle to avoid demangling symbols.""
when i use -Wl,--no-demangle with gcc it again raise the same message

I think its related with reserved identifiers used by gcc.
thats why gcc mangle its name.

Dont you think there should be some name backtracking feature should be added
in gcc to give correct name to the user after name mangling.


i am unaware this feature. If some feature is available in gcc then can you
please help me regarding this



(In reply to comment #1)
> Because the linker demangles symbols and __ct__3abcFv is the mangled form of
> abc::__ct(void).
> 
> Note this is a linker issue and if at all should be filed with the binutils
> bugzilla.  You can use -Wl,--no-demangle to avoid demangling symbols.
> 


-- 

ashutosh dot nema at nechclst dot in changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug rtl-optimization/36006] [4.4 regression] invalid rtl sharing with -O2

[uros at gcc dot gnu dot org]

--- Comment #5 from uros at gcc dot gnu dot org  2008-04-24 04:54 ---
Subject: Bug 36006

Author: uros
Date: Thu Apr 24 04:53:47 2008
New Revision: 134618

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134618
Log:
PR rtl-optimization/36006
* expmed.c (store_fixed_bit_field): Copy op0 rtx before moving
temp to op0 in order to avoid invalid rtx sharing.

testsuite/ChangeLog:

PR rtl-optimization/36006
* gfortran.dg/pr36006-1.f90: New test.
* gfortran.dg/pr36006-2.f90: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/pr36006-1.f90
trunk/gcc/testsuite/gfortran.dg/pr36006-2.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-04-24 03:55 
---
Subject: Bug 35994

Author: jvdelisle
Date: Thu Apr 24 03:55:05 2008
New Revision: 134616

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134616
Log:
2008-04-23  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/35994
* gfortran.dg/minmaxloc_5.f90: New test.
* gfortran.dg/minmaxloc_6.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/minmaxloc_5.f90
trunk/gcc/testsuite/gfortran.dg/minmaxloc_6.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-04-24 03:49 
---
Fixed on 4.4, needs to be backported to 4.3.1


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-04-22 18:43:07 |2008-04-24 03:49:44
   date||


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

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-04-24 03:48 
---
Subject: Bug 35994

Author: jvdelisle
Date: Thu Apr 24 03:48:00 2008
New Revision: 134615

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134615
Log:
2008-04-23  Jerry DeLisle  <[EMAIL PROTECTED]>
Francois-Xavier Coudert  <[EMAIL PROTECTED]>

PR fortran/35994
* trans-instrinsic.c (gfc_conv_intrinsic_minmaxloc): Correctly adjust
loop counter offset.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-intrinsic.c


-- 


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

[Bug libstdc++/36032] New: -fno-exceptions breaks simple if-statement.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  #include 

  int main()
  {
if(true) try {} catch(int) {}
else std::cout << "bla\n";
  }

When compiled without -fno-exceptions, "bla" is not printed (which is correct).
When compiled /with/ -fno-exceptions, "bla" /is/ printed (which is not
correct).

This appears to be due to the following overly simplistic definitions in
libsupc++/exception_defines.h:

  #ifndef __EXCEPTIONS
  // Iff -fno-exceptions, transform error handling code to work without it.
  # define try  if (true)
  # define catch(X) if (false)


-- 
   Summary: -fno-exceptions breaks simple if-statement.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
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=36032

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-04-24 02:04 
---
FX, I will test the patch tonight and see how it works and if good, submit to
list for approval.


-- 


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

[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)

[anhvofrcaus at gmail dot com]

--- Comment #4 from anhvofrcaus at gmail dot com  2008-04-24 01:32 ---
Samuel:


That is exactly my point. Pak1.= operator only operates on T1. The conversion
Pak1.T1(Z1) and Pak1.T1(Z2) will drop component F1. Thus, as I said before
Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2)) always yields True. In the meantime,
Pak2.Eq(Z1, Z2) always returns False. Therefore, comparing True and False
should yield False. 


-- 

anhvofrcaus at gmail dot com changed:

   What|Removed |Added

 CC||anhvofrcaus at gmail dot com


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

[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)

[ludovic at ludovic-brenta dot org]

--- Comment #3 from ludovic at ludovic-brenta dot org  2008-04-23 23:47 
---
Exactly. The quoted portion of the ARM says that Pak2.Eq (Z1, Z2) should
implicitly convert Z1 and Z2 to type T1, then call Pak1.Eq, then return True. 
Instead, it returns False as though GNAT synthesised a new

function Eq (X, Y : T2) return Boolean renames "=";

inside of Pak2, where "=" is the predefined equality operator for T2.  This
synthetic function overrides Pak1.Eq without the programmer's consent.


-- 


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

[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-04-23 23:21 ---
Anh Vo: I think that you are wrong and that Ludovic is right. Note that Eq (T2,
T2) is not a renaming of T2 "=" operator, it is, through inheritance, a
renaming of T1 "=" operator with signature

  function "=" (X, Y : T1) return Boolean;

Note that this function knows *nothing* about T2, so it cannot obviously
compare new fields added in T2, it only compares fields already present in T1.


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sam at gcc dot gnu dot org


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

[Bug debug/27574] [4.1/4.2/4.3/4.4 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor

[pinskia at gcc dot gnu dot org]

--- Comment #22 from pinskia at gcc dot gnu dot org  2008-04-23 23:08 
---
(In reply to comment #21)
> A patch like this seems like a decent workaround to me.
> 
> Honza, any opinions on this approach?

This looks good to me also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/36006] [4.4 regression] invalid rtl sharing with -O2

[nightstrike at gmail dot com]

--- Comment #4 from nightstrike at gmail dot com  2008-04-23 23:04 ---
(In reply to comment #3)
> > BTW: The testcase  doesn't fail for x86_64-linux. Can you please regression
> > test the patch (and write a testcase ;) on *-mingw target?
> I'm not set up for regtesting on x86_64-mingw32 (nor on 32-bit mingw32, in any
> case), but I checked that your patch does fix both the reduced and the 
> original
> testcase (sent to me by private mail).

I am set up for running the testsuite on x86_64-pc-mingw32, however it takes
several days to complete.  Is there a reduced set of tests that I can run?


-- 


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

[Bug target/32871] [avr] Bad optimisation - gcc is pushing too many registers

[eric dot weddington at atmel dot com]

--- Comment #5 from eric dot weddington at atmel dot com  2008-04-23 22:55 
---
Patch causes wrong code regression. See WinAVR bug #1945375 on SourceForge:



-- 


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

[Bug middle-end/35992] [4.4 Regression] Linux kernel code fails to compile with -Os

[ian at airs dot com]

--- Comment #6 from ian at airs dot com  2008-04-23 22:46 ---
This is fixed by this patch:

2008-04-22  Ian Lance Taylor  <[EMAIL PROTECTED]>

* fold-const.c (pointer_may_wrap_p): Call int_size_in_bytes rather
than size_in_bytes.

Sorry about the difficulties.


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/35954] [4.3/4.4 Regression] cannot build from read-only source tree

[rwild at gcc dot gnu dot org]

--- Comment #3 from rwild at gcc dot gnu dot org  2008-04-23 22:42 ---
Subject: Bug 35954

Author: rwild
Date: Wed Apr 23 22:41:10 2008
New Revision: 134605

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134605
Log:
libstdc++-v3/
PR libstdc++/35954
* include/Makefile.am (pch*_output): Do not touch pch*_output_anchor.
Call 'mkdir -p' unconditionally, but ignore its return value.
* include/Makefile.in: Regenerate.

Modified:
branches/gcc-4_3-branch/libstdc++-v3/ChangeLog
branches/gcc-4_3-branch/libstdc++-v3/include/Makefile.am
branches/gcc-4_3-branch/libstdc++-v3/include/Makefile.in


-- 


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

[Bug debug/27574] [4.1/4.2/4.3/4.4 Regression] MIssing debug info at -O0 for a local variable in a C++ constructor

[ian at airs dot com]

--- Comment #21 from ian at airs dot com  2008-04-23 22:33 ---
A patch like this seems like a decent workaround to me.

Honza, any opinions on this approach?

Ian

Index: cgraph.c
===
--- cgraph.c(revision 134283)
+++ cgraph.c(working copy)
@@ -615,6 +615,14 @@ cgraph_remove_node (struct cgraph_node *
kill_body = true;
 }

+  /* We don't release the body of abstract functions, because they may
+ be needed when emitting debugging information.  In particular
+ this will happen for C++ constructors/destructors.  FIXME:
+ Ideally we would check to see whether there are any reachable
+ functions whose DECL_ABSTRACT_ORIGIN points to this decl.  */
+  if (DECL_ABSTRACT (node->decl))
+kill_body = false;
+
   if (kill_body && flag_unit_at_a_time)
 cgraph_release_function_body (node);
   node->decl = NULL;


-- 


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

[Bug target/36031] New: ARM -fshort-enums attribute not emitted for Fortran

[drow at gcc dot gnu dot org]

The -fshort-enums option emits a note in the object file that the linker can
use to detect mismatches.  It does not work for Fortran; the "int-sized enums"
attribute is emitted with or without -fshort-enums.


-- 
   Summary: ARM -fshort-enums attribute not emitted for Fortran
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi


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

[Bug bootstrap/36027] Build does not properly detect gmp and mpfr

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-23 22:04 ---
gcc-4.3.0/libstdc++-v3/include/precompiled/stdc++.h -o
i686-pc-linux-gnu/bits/stdc++.h.gch/O0g.gch
/home/jrevans/src/COTS-Build/build_src/gcc-4.3.0-BUILD/./gcc/cc1plus: error
while loading shared libraries: libmpfr.so.1: cannot open shared object file:
No such file or directory


-- 


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

[Bug c/36024] Incorrect function name in linking error

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-23 22:01 ---
Also by the way any name that starts with two underscores is in the reserved
implementation namespace so demangling to something weird is ok. 


-- 


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

[Bug ada/32181] Legal program executes incorrectly, RM 3.4(27)

[anhvofrcaus at gmail dot com]

--- Comment #1 from anhvofrcaus at gmail dot com  2008-04-23 21:59 ---
The GNAT behaves correctly by printing FAILED because the test code has a
problem. When converting Child type to the Parent type, any component(s) of the
Child type will be lost. Therefore, Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2) should
return True (due to the Parent type having null record), and Pak2.Eq(Z1, Z2)
should return False because the objects are different obviously. Thus, the
equality Pak2.Eq(Z1, Z2) = Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2)) should evaluate to
False. In summary, the equality should be changed to inequality as shown below.

with Text_IO; use Text_IO;
procedure Test1 is
   package Pak1 is
  type T1 is tagged null record;
  function Eq(X, Y: T1) return Boolean renames "=";
   end Pak1;

   package Pak2 is
  type T2 is new Pak1.T1 with record
 F1: Integer;
  end record;
   end Pak2;

   Z1: Pak2.T2 := (F1 => 1);
   Z2: Pak2.T2 := (F1 => 2);
begin
   if Pak2.Eq(Z1, Z2) /= Pak1.Eq(Pak1.T1(Z1), Pak1.T1(Z2))
  then Put_Line("PASSED");
  else Put_Line("FAILED");
   end if;
end Test1;


-- 


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

[Bug other/36030] Throwing exceptions in multiple threads leads to spinning in call to _Unwind_Find_FDE

[an at atrn dot org]

--- Comment #3 from an at atrn dot org  2008-04-23 21:36 ---
Note for repro using glibc, the test program uses the BSD err() function to
report errors and quit.  A quick look at glibc's manual says it has a
compatible err() function but declared in error.h not err.h as in BSD.


-- 

an at atrn dot org changed:

   What|Removed |Added

 CC||an at atrn dot org


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

[Bug tree-optimization/34265] Missed optimizations

[dominiq at lps dot ens dot fr]

--- Comment #33 from dominiq at lps dot ens dot fr  2008-04-23 21:26 ---
Created an attachment (id=15523)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15523&action=view)
induct.f90 variants and their diff with the original file

The original diff's have space problems.


-- 


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

[Bug c++/36030] Throwing exceptions in multiple threads leads to spinning in call to _Unwind_Find_FDE

[an at atrn dot org]

--- Comment #2 from an at atrn dot org  2008-04-23 21:25 ---
Created an attachment (id=15522)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15522&action=view)
Patch to protect against concurrent modifications to frame cache

Simple fix that applies coarse-grained locking around the frame cache.  If
unwinding performance is a concern either a finer-grain locking strategy or
even a lock-free structure should be used.


-- 


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

[Bug c++/36030] Throwing exceptions in multiple threads leads to spinning in call to _Unwind_Find_FDE

[an at atrn dot org]

--- Comment #1 from an at atrn dot org  2008-04-23 21:22 ---
Created an attachment (id=15521)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15521&action=view)
test program

Test program to demonstrate issue


-- 


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

[Bug c++/36030] New: Throwing exceptions in multiple threads leads to spinning in call to _Unwind_Find_FDE

[an at atrn dot org]

gcc/unwind-dw2-fde-glibc.c maintains a cache of frames via its dl_iterate_phdr
callback but doesn't protect against multiple threads modifying that cache
concurrently.  A simple test program that starts N threads, all of which
immediately throw, often, but not always (as such races are prone to behave),
leads to some number of threads stuck inside their stack unwinding consuming
100% CPU.  The particular failure mode will no doubt differ depending upon the
particular interleaving of accesses/modifications to the cache structure but
I'm seeing consistent hangs on the two systems on which I've tested this (quad
core Xeon, dual core Core 2 Duo).

Reproduction typically requires running the test in a loop until it doesn't
exit.  The usual caveats regarding races apply, i.e it may not fail on certain
CPU/OS combinations or may take a long time to fail.

The attached patch avoids the spinning by grabbing "object_mutex" (defined in
gcc/unwind-dw2-fde.c which is included and used in gcc/unwind-dw2-fde-glibc.c)
to protect against multiple threads manipulating the cache at the same time.

With the patch no failure has been observed in over 200,000 invocations of the
test with each invocation starting 100 threads.

The issue was found on FreeBSD 7.x (aka STABLE) gcc 4.2.1 (20070719) but
inspection of the VCS shows the same code exists on the trunk and branches.


-- 
   Summary: Throwing exceptions in multiple threads leads to
spinning in call to _Unwind_Find_FDE
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: an at atrn dot org
 GCC build triplet: i386-undermydesk-freebsd
  GCC host triplet: i386-undermydesk-freebsd
GCC target triplet: i386-undermydesk-freebsd


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

[Bug fortran/35990] run-time abort for PACK of run-time zero sized array

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-04-23 20:32 ---
Created an attachment (id=15520)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15520&action=view)
(first) patch

This fixes the test case, at least, and passes a test of
all *pack* test cases.

I'll have to see if other code paths have a similar problem.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/36006] [4.4 regression] invalid rtl sharing with -O2

[ubizjak at gmail dot com]

-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||04/msg01762.html
 Status|NEW |ASSIGNED
  Component|tree-optimization   |rtl-optimization
   Last reconfirmed|2008-04-23 17:28:45 |2008-04-23 19:53:36
   date||
Summary|[4.4 regression] invalid rtl|[4.4 regression] invalid rtl
   |with -O2|sharing with -O2


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

[Bug translation/35177] Error in the french traduction

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-04-23 19:29 
---
Fixed sent to TP, closing this report. Thanks again!


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-04-23 19:29 ---
Additional point, one needs to take care also of continuation lines of the
following kind. This should print "Hello Paul" and not "Hello Hans".

#define Paul Hans
! Paul's string
print *,'Hello &
  &Paul'
end


-- 


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

[Bug fortran/36029] New: Off-by-one runtime bounds checking message

[fxcoudert at gcc dot gnu dot org]

$ cat > a.f90
program test 
 integer, dimension(:), allocatable :: x 
 allocate(x(10)) 
 call use_array(x) 
contains 
 subroutine use_array(x) 
 integer, dimension(:), intent(in) :: x 
 integer, dimension(20) :: y 
 y = x 
 end subroutine use_array 
end program 

$ gfortran -fbounds-check a.f90 && ./a.out
At line 9 of file a.f90
Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of
array 'y' (19/9)


-- 
   Summary: Off-by-one runtime bounds checking message
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug tree-optimization/36006] [4.4 regression] invalid rtl with -O2

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-04-23 18:27 
---
> BTW: The testcase  doesn't fail for x86_64-linux. Can you please regression
> test the patch (and write a testcase ;) on *-mingw target?

I'm not set up for regtesting on x86_64-mingw32 (nor on 32-bit mingw32, in any
case), but I checked that your patch does fix both the reduced and the original
testcase (sent to me by private mail). I propose to add the following
testcases:

$ cat z1.f90 
! { dg-do compile }
!
subroutine test4
  integer, parameter :: wp = 4
  complex(wp), parameter :: i = (0._wp, 1._wp)
  complex(wp) :: c(12)
  integer :: m, N

  N = 12
  c = (/(exp(i*m),m=1,N)/)
  print *, c(1)
end

subroutine test8
  integer, parameter :: wp = 8
  complex(wp), parameter :: i = (0._wp, 1._wp)
  complex(wp) :: c(12)
  integer :: m, N

  N = 12
  c = (/(exp(i*m),m=1,N)/)
  print *, c(1)
end

$ cat z2.f90 
! { dg-do compile }
! { dg-require-effective-target fortran_large_real }
!
subroutine test_large
  integer, parameter :: wp = selected_real_kind (precision (0.0_8) + 1)
  complex(wp), parameter :: i = (0._wp, 1._wp)
  complex(wp) :: c(12)
  integer :: m, N

  N = 12
  c = (/(exp(i*m),m=1,N)/)
  print *, c(1)
end


 (I think covering all real types is a good idea, in that case.)


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug c/36028] [IRA] ICE in reload_cse_simplify_operands

[aldot at gcc dot gnu dot org]

--- Comment #2 from aldot at gcc dot gnu dot org  2008-04-23 17:30 ---
Created an attachment (id=15519)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15519&action=view)
original testcase


-- 


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

[Bug c/36028] [IRA] ICE in reload_cse_simplify_operands

[aldot at gcc dot gnu dot org]

--- Comment #1 from aldot at gcc dot gnu dot org  2008-04-23 17:30 ---
Created an attachment (id=15518)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15518&action=view)
slightly reduced testcase from bash


-- 


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

[Bug c/36028] New: [IRA] ICE in reload_cse_simplify_operands

[aldot at gcc dot gnu dot org]

ira branch, rev134590, building bash-3.2 gives:

gcc -w -c -o subst.o subst.12.i -O3 -fira
subst.12.i: In function 'parameter_brace_substring':
subst.12.i:73: error: insn does not satisfy its constraints:
(insn 243 14 244 2 subst.12.i:53 (set (mem/c:TI (plus:SI (reg/f:SI 6 bp)
(const_int -104 [0xff98])) [0 S16 A8])
(reg:TI 0 ax)) 64 {*movti_internal} (nil))
subst.12.i:73: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:395


Target: i686-linux-uclibc
Configured with: /there.pentium4/toolchain_build_i686/gcc-4.4.0/configure
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=i686-linux-uclibc --enable-languages=c,fortran
--with-sysroot=/there.pentium4/build_i686/staging_dir
--with-build-time-tools=/there.pentium4/build_i686/staging_dir/usr/i686-linux-uclibc/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared
--with-gmp=/there.pentium4/toolchain_build_i686/gmp
--with-mpfr=/there.pentium4/toolchain_build_i686/mpfr --disable-nls
--enable-threads --disable-multilib --with-arch=nocona --with-tune=nocona
--disable-largefile --disable-libgomp
Thread model: posix
gcc version 4.4.0 20080328 (experimental) (GCC)


-- 
   Summary: [IRA] ICE in reload_cse_simplify_operands
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
  GCC host triplet: i386


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

[Bug tree-optimization/36006] [4.4 regression] invalid rtl with -O2

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-04-23 17:28 ---
Index: expmed.c
===
--- expmed.c(revision 134561)
+++ expmed.c(working copy)
@@ -976,7 +976,10 @@ store_fixed_bit_field (rtx op0, unsigned
 }

   if (op0 != temp)
-emit_move_insn (op0, temp);
+{
+  op0 = copy_rtx (op0);
+  emit_move_insn (op0, temp);
+}
 }


 /* Store a bit field that is split across multiple accessible memory objects.

The above patch fixes invalid rtl sharing.

BTW: The testcase  doesn't fail for x86_64-linux. Can you please regression
test the patch (and write a testcase ;) on *-mingw target?


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-23 17:28:45
   date||


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

[Bug rtl-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-04-23 16:53 ---
And one with just one inlined fn:
extern void abort (void);

void __attribute__ ((noinline))
bar (int m[3][3], int a[3][3], int b[3][3])
{
  int i, j;
  for (i = 0; i < 3; i++)
for (j = 0; j < 3; j++)
  m[i][j] = a[i][0] * b[0][j] + a[i][1] * b[1][j] + a[i][2] * b[2][j];
}

static inline void __attribute__ ((always_inline))
foo (int x[][3][3], int g[3][3], int y, int z)
{
  int i, j, k;
  for (i = 0; i < y; i++)
for (j = 0; j < z - 1; j++)
  {
k = i * (z - 1) + j + y;
bar (x[k], g, x[k - y]);
  }
}

int g[48][3][3] = {
{ {1, 0, 0}, {0, 1, 0}, {0, 0, 1} }, { {-1, 0, 0}, {0, -1, 0}, {0, 0, -1} },
{ {-1, 0, 0}, {0, 1, 0}, {0, 0, -1} }, { {1, 0, 0},  {0, -1, 0}, {0, 0, 1} },
{ {-1, 0, 0}, {0, -1, 0}, {0, 0, 1} }, { {1, 0, 0}, {0, 1, 0}, {0, 0, -1} },
{ {1, 0, 0}, {0, -1, 0}, { 0, 0, -1} }, { {-1, 0, 0}, {0, 1, 0}, {0, 0, 1} } };
int h[3][3] = { {0, 1, 0}, {1, 0, 0}, {0, 0, 1} };

int
main ()
{
  foo (g, h, 8, 2);
  if (g[1][1][0] != 0)
abort ();
  return 0;
}


-- 


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

[Bug c++/33486] namespace association doesn't handle parallel namespaces

[bkoz at gcc dot gnu dot org]

--- Comment #11 from bkoz at gcc dot gnu dot org  2008-04-23 16:40 ---

fixed on trunk and gcc-4_3-branch


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-04-23 16:35 ---
Even more simplified testcase, with just one CU.  Works at -O0/-O/-O2, fails at
-O{,2} -funroll-loops or -O3.
extern void abort (void);

void __attribute__ ((noinline))
bar (int m[3][3], int a[3][3], int b[3][3])
{
  int i, j;
  for (i = 0; i < 3; i++)
for (j = 0; j < 3; j++)
  m[i][j] = a[i][0] * b[0][j] + a[i][1] * b[1][j] + a[i][2] * b[2][j];
}

static inline void __attribute__ ((always_inline))
foo (int x[][3][3], int g[3][3], int y, int z)
{
  int i, j, k;
  for (i = 0; i < y; i++)
for (j = 0; j < z - 1; j++)
  {
k = i * (z - 1) + j + y;
bar (x[k], g, x[k - y]);
  }
}

int g1[48][3][3] = { { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} } };
int g2[3][3] = { {-1, 0, 0}, {0, -1, 0}, {0, 0, -1} };
int g3[3][3] = { {0, 1, 0}, {1, 0, 0}, {0, 0, 1} };
int g4[3][3] = { {-1, 0, 0}, {0, 1, 0}, {0, 0, -1} };
int g5[3][3] = { {-1, 0, 0}, {0, -1, 0}, {0, 0, 1} };

int
main ()
{
  foo (g1, g2, 1, 2);
  foo (g1, g4, 2, 2);
  foo (g1, g5, 4, 2);
  foo (g1, g3, 8, 2);
  if (g1[1][1][0] != 0)
abort ();

  return 0;
}


-- 


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

[Bug bootstrap/36027] Build does not properly detect gmp and mpfr

[jrevans1 at earthlink dot net]

--- Comment #1 from jrevans1 at earthlink dot net  2008-04-23 15:41 ---
Created an attachment (id=15517)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15517&action=view)
Build log with error at end.

A gzipped text file of the build output.


-- 


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

[Bug bootstrap/36027] New: Build does not properly detect gmp and mpfr

[jrevans1 at earthlink dot net]

I have a very clean build environment with a minimalistic set of env vars.  My
system (RHEL4) did not have an existsing gmp and mpfr, so I build them using
the standard steps and installed them to a local directory.  I configured gcc
the first time and forgot to point to where gmp and mpfr were and the configure
failed (as would be expected).  So I started over and pointed gcc to the proper
place:

Configured with: /home/jrevans/src/COTS-Build/build_src/gcc-4.3.0/configure
--prefix=/home/jrevans/src/COTS-Build/build_local --enable-languages=c,c++
--with-gmp=/home/jrevans/src/COTS-Build/build_local
--with-mpfr=/home/jrevans/src/COTS-Build/build_local

I build with the following command, and get an error (see attached):
make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' bootstrap

I set my PATH and LD_LIBRARY_PATH environments variables to point to the
location of the installed gmp and mpfr and still get the same error.  I finally
was able to build successfully after setting the PATH and LD_LIBRARY_PATH
variables in my '.cshrc' file to point to the installed gmp and mpfr location.

This seems to me that the gcc build should pick up the gmp and mpfr pointed to
in the configure step and never need any environment variable to tell it where
things are.


-- 
   Summary: Build does not properly detect gmp and mpfr
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrevans1 at earthlink dot net
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/36026] optimized code returns different results

[l dot jirkovsky at gmail dot com]

--- Comment #8 from l dot jirkovsky at gmail dot com  2008-04-23 15:18 
---
Thanks a lot. Actually I'm a very beginner in C++ and I don't understand this
code a lot.


-- 


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

[Bug c/36026] optimized code returns different results

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-04-23 14:48 ---
Btw:

gcc-4.3 -o t test_simple.c -O2 -Wstrict-overflow
test_simple.c: In function 'v_bignum_square_half':
test_simple.c:96: warning: assuming signed overflow does not occur when
simplifying conditional to constant


-- 


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

[Bug c/36026] optimized code returns different results

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-04-23 14:32 ---
-fno-tree-vrp "fixes" it, but

D.2830_35: [0, 65535]
D.2839_49: [0, 65535]
D.2840_56: [0, +INF(OVF)]

  D.2829_34 = *D.2828_33;
  D.2830_35 = (int) D.2829_34;
...
  D.2838_48 = *D.2837_47; 
  D.2839_49 = (int) D.2838_48;
  D.2840_56 = D.2830_35 * D.2839_49;
  high_59 = D.2840_56 < 0;

looks suspiciously like a case of signed integer overflow undefinedness.

uv = x[1 + j] * x[1 + i];
high = (uv & 0x8000) != 0;

the multiplication will be carried out in signed int because VBigDig, the
type of *x, unsigned short, promotes to int.  Thus the above is equivalent to

   uv = (unsigned int)((int)x[1 + j] * (int)x[1 + i]);
   high = (uv & 0x8000) != 0;

at which the compiler can conclude that the result of the multiplication
is never negative.  Fix this by doing

uv = (VBigDigs)x[1 + j] * (VBigDigs)x[1 + i];
high = (uv & 0x8000) != 0;

instead.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c/36026] optimized code returns different results

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-04-23 14:26 ---
Looking at it.


-- 


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

[Bug c/36026] optimized code returns different results

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-23 14:16 ---
ok, there are subtle differences (too large number to look at), but which is
correct, which is incorrect?


-- 


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

[Bug c/36026] optimized code returns different results

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-23 14:15 ---
What is correct, what is incorrect output?  I get the same output

0x91F915BFDFAA69101B4D0720E517E6EAFAF7B231ADFFBBCDA5D630F51644A3466EC239357DA5989680018670CAAA4CA9CF5383B2E71A933A5608E3155DFF5071

for 3.3, 4.1, 4.2 and 4.3 for x86_64 and i686.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/32624] r126198 causes tramp3d slowdown w/o leafify

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-23 14:10 
---
Fixed for GCC 4.4.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail||4.3.0
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #42 from rguenth at gcc dot gnu dot org  2008-04-23 14:09 
---
Likely fixed on the mainline.


-- 


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

[Bug tree-optimization/32921] [4.3/4.4 Regression] Revision 126326 causes 12% slowdown

[rguenth at gcc dot gnu dot org]

--- Comment #41 from rguenth at gcc dot gnu dot org  2008-04-23 14:09 
---
Subject: Bug 32921

Author: rguenth
Date: Wed Apr 23 14:08:25 2008
New Revision: 134598

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

PR tree-optimization/27799
PR tree-optimization/32921
PR tree-optimization/32624
* tree-ssa-structalias.c (merge_smts_into): Only merge the
SMTs aliases and the tag itself into the solution.
* tree-ssa-alias.c (compute_flow_sensitive_aliasing): Do not
merge the points-to solution back into the SMT aliases.
(may_alias_p): Use alias_set_subset_of instead of
aliases_conflict_p.  A pointer which points to
memory with alias set zero may access any variable.

* gcc.dg/tree-ssa/pr27799.c: New testcase.
* gcc.dg/tree-ssa/20030807-7.c: Remove xfail, scan vrp dump.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr27799.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030807-7.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug middle-end/32624] r126198 causes tramp3d slowdown w/o leafify

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-04-23 14:09 ---
Subject: Bug 32624

Author: rguenth
Date: Wed Apr 23 14:08:25 2008
New Revision: 134598

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

PR tree-optimization/27799
PR tree-optimization/32921
PR tree-optimization/32624
* tree-ssa-structalias.c (merge_smts_into): Only merge the
SMTs aliases and the tag itself into the solution.
* tree-ssa-alias.c (compute_flow_sensitive_aliasing): Do not
merge the points-to solution back into the SMT aliases.
(may_alias_p): Use alias_set_subset_of instead of
aliases_conflict_p.  A pointer which points to
memory with alias set zero may access any variable.

* gcc.dg/tree-ssa/pr27799.c: New testcase.
* gcc.dg/tree-ssa/20030807-7.c: Remove xfail, scan vrp dump.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr27799.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030807-7.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-23 14:09 
---
Subject: Bug 27799

Author: rguenth
Date: Wed Apr 23 14:08:25 2008
New Revision: 134598

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

PR tree-optimization/27799
PR tree-optimization/32921
PR tree-optimization/32624
* tree-ssa-structalias.c (merge_smts_into): Only merge the
SMTs aliases and the tag itself into the solution.
* tree-ssa-alias.c (compute_flow_sensitive_aliasing): Do not
merge the points-to solution back into the SMT aliases.
(may_alias_p): Use alias_set_subset_of instead of
aliases_conflict_p.  A pointer which points to
memory with alias set zero may access any variable.

* gcc.dg/tree-ssa/pr27799.c: New testcase.
* gcc.dg/tree-ssa/20030807-7.c: Remove xfail, scan vrp dump.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr27799.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030807-7.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-structalias.c


--- Comment #11 from rguenth at gcc dot gnu dot org  2008-04-23 14:09 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/27799] adding unused char field inhibits optimization

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-23 14:09 
---
Subject: Bug 27799

Author: rguenth
Date: Wed Apr 23 14:08:25 2008
New Revision: 134598

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

PR tree-optimization/27799
PR tree-optimization/32921
PR tree-optimization/32624
* tree-ssa-structalias.c (merge_smts_into): Only merge the
SMTs aliases and the tag itself into the solution.
* tree-ssa-alias.c (compute_flow_sensitive_aliasing): Do not
merge the points-to solution back into the SMT aliases.
(may_alias_p): Use alias_set_subset_of instead of
aliases_conflict_p.  A pointer which points to
memory with alias set zero may access any variable.

* gcc.dg/tree-ssa/pr27799.c: New testcase.
* gcc.dg/tree-ssa/20030807-7.c: Remove xfail, scan vrp dump.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr27799.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/20030807-7.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-23 13:59:59
   date||


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

[Bug c/36021] [4.3/4.4 Regression] __attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-04-23 13:56 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/36021] [4.3/4.4 Regression] __attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-23 13:53 ---
Subject: Bug 36021

Author: rguenth
Date: Wed Apr 23 13:52:46 2008
New Revision: 134596

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

PR middle-end/36021
* c-common.c (handle_alloc_size_attribute): Use type_num_arguments.

* gcc.dg/attr-alloc_size-2.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/attr-alloc_size-2.c
  - copied unchanged from r134595,
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-2.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/c-common.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35965] -fstack-protector produces segfaulting binaries on arm/armel

[riku dot voipio at iki dot fi]

--- Comment #3 from riku dot voipio at iki dot fi  2008-04-23 13:49 ---
This is also reproducible with codesourcery 2008q1

Using built-in specs.
Target: arm-none-linux-gnueabi
Configured with: /scratch/sandra/lite/src/gcc-4.2/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch --with-gnu-as
--with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion=Sourcery G++ Lite 2008q1-126
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/codesourcery
--with-sysroot=/opt/codesourcery/arm-none-linux-gnueabi/libc
--with-build-sysroot=/scratch/sandra/lite/linux/install/arm-none-linux-gnueabi/libc
--enable-poison-system-directories
--with-build-time-tools=/scratch/sandra/lite/linux/install/arm-none-linux-gnueabi/bin
--with-build-time-tools=/scratch/sandra/lite/linux/install/arm-none-linux-gnueabi/bin
Thread model: posix
gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126)


-- 


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

[Bug c/36021] [4.3/4.4 Regression] __attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-23 13:48 ---
Subject: Bug 36021

Author: rguenth
Date: Wed Apr 23 13:47:38 2008
New Revision: 134595

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

PR middle-end/36021
* c-common.c (handle_alloc_size_attribute): Use type_num_arguments.

* gcc.dg/attr-alloc_size-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-04-23 13:29 ---
I've instead regtested:
--- gcc/config/i386/i386.c.jj   2008-04-01 13:34:27.0 +0200
+++ gcc/config/i386/i386.c  2008-04-23 13:38:14.0 +0200
@@ -3501,7 +3501,7 @@ init_cumulative_args (CUMULATIVE_ARGS *c
 {
   /* If there are variable arguments, then we won't pass anything
  in registers in 32-bit mode. */
-  if (cum->maybe_vaarg) 
+  if (stdarg_p (fntype))
{
  cum->nregs = 0;
  cum->sse_nregs = 0;

patch (on i686 only, as this is !TARGET_64BIT hunk of code).
IMHO it best matches what 4.2 and earlier did.  Here is the 4.2 code:
  cum->maybe_vaarg = false;
...
  /* Determine if this function has variable arguments.  This is
 indicated by the last argument being 'void_type_mode' if there
 are no variable arguments.  If there are variable arguments, then
 we won't pass anything in registers in 32-bit mode. */

  if (cum->nregs || cum->mmx_nregs || cum->sse_nregs)
{
  for (param = (fntype) ? TYPE_ARG_TYPES (fntype) : 0;
   param != 0; param = next_param)
{
  next_param = TREE_CHAIN (param);
  if (next_param == 0 && TREE_VALUE (param) != void_type_node)
{
  if (!TARGET_64BIT)
{
  cum->nregs = 0;
  cum->sse_nregs = 0;
  cum->mmx_nregs = 0;
  cum->warn_sse = 0; 
  cum->warn_mmx = 0; 
  cum->fastcall = 0; 
  cum->float_in_sse = 0;
}
  cum->maybe_vaarg = true;
}
}
}
  if ((!fntype && !libname)
  || (fntype && !TYPE_ARG_TYPES (fntype)))
cum->maybe_vaarg = true;

The param/next_param testing IMHO is stdarg_p test, so cum->nregs etc. are
cleared only if !TARGET_64BIT && stdarg_p (fntype).  maybe_vaarg is set if
stdarg_p (fntype), or for fntype && !prototype_p (fntype), or for !fntype &&
!libname.


-- 


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

[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-04-23 13:07 ---
(In reply to comment #2)
> Caused I believe by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835
> likely together with http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01511.html
> While in 4.2 functions with fntype without TYPE_ARG_TYPES (i.e. !prototype_p)
> nregs, etc. would be preserved and maybe_vaarg set to true only afterwards,
> in 4.3 it is set early and the calling convention is forced to stack.
> 
> maybe_vaarg is only used in 2 places - in init_cumulative_args itself, in
> !TARGET_64BIT case only, and in function_arg_64 (i.e. TARGET_64BIT case only).
> If we want to restore 4.2 and earlier behavior (I think we have to), then
> one fix could be e.g. only set maybe_vaarg to true for !prototype_p (fntype)
> if TARGET_64BIT.
> -  ? (!prototype_p (fntype) || stdarg_p (fntype))
> +  ? ((TARGET_64BIT && !prototype_p (fntype))
> + || stdarg_p (fntype))
> 
> As K&R fn declaration (i.e. !prototype_p) followed by stdarg_p definition or
> prototype is diagnosed as an error by diagnose_arglist_conflict, I believe 
> this
> is safe.
> 

Can you give it a try on both Linux/ia32 and Linux/x86-64?


-- 


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

[Bug c/36026] optimized code returns different results

[l dot jirkovsky at gmail dot com]

--- Comment #2 from l dot jirkovsky at gmail dot com  2008-04-23 11:37 
---
thanks to Ketling (one guy who helps me with identifying the bug) there is more
progress:
high = (uv & 0x8000) != 0; is always zero.


-- 


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

[Bug c/36026] optimized code returns different results

[l dot jirkovsky at gmail dot com]

--- Comment #1 from l dot jirkovsky at gmail dot com  2008-04-23 11:28 
---
Created an attachment (id=15516)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15516&action=view)
test code from verse


-- 


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

[Bug c/36026] New: optimized code returns different results

[l dot jirkovsky at gmail dot com]

Hi,
I've code from verse (http://verse.blender.org/) which returns different
results when run with optimizations.

Steps to reproduce:
run gcc test_simple.c
then run compiled program and see what it prints.
compile it with gcc -O2 (or higher). Resulting executable returns different
result.

Tested gcc versions:
3.4.6 - everything works there
4.3.0 - bug is reproducible
4.1.2 - the same as 4.3.0

I've tried to turn on optimization flags which are enabled by -O2 by parts (At
first first half and then second half of flags) but in this case the problem is
not present.


-- 
   Summary: optimized code returns different results
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: l dot jirkovsky at gmail dot com


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

[Bug rtl-optimization/36008] [4.3/4.4 Regression] Function produces wrong results when inlined.

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-04-23 11:02 ---
This goes wrong somewhere during RTL optimization.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |rtl-optimization
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-23 11:02:01
   date||
Summary|Function produces wrong |[4.3/4.4 Regression]
   |results when inlined.   |Function produces wrong
   ||results when inlined.
   Target Milestone|--- |4.3.1


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

[Bug target/36015] [4.3/4.4 Regression] -mregparm and fn decls without arguments

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-04-23 10:45 ---
Caused I believe by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835
likely together with http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01511.html
While in 4.2 functions with fntype without TYPE_ARG_TYPES (i.e. !prototype_p)
nregs, etc. would be preserved and maybe_vaarg set to true only afterwards,
in 4.3 it is set early and the calling convention is forced to stack.

maybe_vaarg is only used in 2 places - in init_cumulative_args itself, in
!TARGET_64BIT case only, and in function_arg_64 (i.e. TARGET_64BIT case only).
If we want to restore 4.2 and earlier behavior (I think we have to), then
one fix could be e.g. only set maybe_vaarg to true for !prototype_p (fntype)
if TARGET_64BIT.
-  ? (!prototype_p (fntype) || stdarg_p (fntype))
+  ? ((TARGET_64BIT && !prototype_p (fntype))
+ || stdarg_p (fntype))

As K&R fn declaration (i.e. !prototype_p) followed by stdarg_p definition or
prototype is diagnosed as an error by diagnose_arglist_conflict, I believe this
is safe.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com, hubicka at gcc dot gnu
   ||dot org


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

[Bug target/35982] [4.3 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970

[irar at gcc dot gnu dot org]

--- Comment #5 from irar at gcc dot gnu dot org  2008-04-23 10:08 ---
Subject: Bug 35982

Author: irar
Date: Wed Apr 23 10:08:01 2008
New Revision: 134588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134588
Log:
PR tree-optimization/35982
* tree-vect-analyze.c (vect_check_interleaving): Check that the
interleaved data-refs are of the same type.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/vect/fast-math-pr35982.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-vect-analyze.c


-- 


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

[Bug middle-end/36008] Function produces wrong results when inlined.

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-04-23 10:03 ---
Created an attachment (id=15515)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15515&action=view)
simplified bravais.c

gcc -c mathfunc.c
gcc -o t.ok bravais.c mathfunc.o -O
gcc -o t.fail bravais.c mathfunc.o -O -funroll-loops

./t.ok
./t.fail
Aborted


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15513|0   |1
is obsolete||


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

[Bug target/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-04-23 09:49 ---
Can't reproduce this with current 4.3 branch nor trunk, x86_64-linux ->
ppc64-linux cross.


-- 


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

[Bug c/36021] [4.3/4.4 Regression] __attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-23 09:38 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-04-23 08:54:29 |2008-04-23 09:38:20
   date||


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

[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning

[pluto at agmk dot net]

--- Comment #27 from pluto at agmk dot net  2008-04-23 09:24 ---
(In reply to comment #26)

> tested on gcc-4.3-svn20080417

fails also on 4.1 and 4.2.


-- 


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

[Bug c/36024] Incorrect function name in linking error

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-04-23 08:56 ---
Because the linker demangles symbols and __ct__3abcFv is the mangled form of
abc::__ct(void).

Note this is a linker issue and if at all should be filed with the binutils
bugzilla.  You can use -Wl,--no-demangle to avoid demangling symbols.


-- 

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

[Bug c/36021] [4.3/4.4 Regression] __attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-23 08:54 ---
Confirmed.  Testcase:

char *foo() __attribute__((alloc_size(2)));


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.3.0
  Known to work||4.2.3
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-04-23 08:54:29
   date||
Summary|__attribute__((alloc_size(n)|[4.3/4.4 Regression]
   |)) with function of no  |__attribute__((alloc_size(n)
   |arguments causes gcc to |)) with function of no
   |segfault|arguments causes gcc to
   ||segfault
   Target Milestone|--- |4.3.1


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

[Bug fortran/35994] [4.3/4.4 regression] MAXLOC and MINLOC off by one with mask

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2008-04-23 08:11 
---
It's not about constantness, but about creating a temporary or not. The
following testcase uses a constant mask and it still gives the right answer:

  REAL DDA(100)
  logical, parameter :: mask(1:100) = (/(J1,J1=1,100)/) > 50
  dda = (/(J1,J1=1,100)/)

  IDS = MAXLOC(DDA,1, mask)
  print *, ids ! expect 100
  END

while the following also uses a compile-time constant mask and gives the wrong
answer (51 when it should be 50):

  REAL DDA(100)
  logical, parameter :: mask(1:100) = (/(J1,J1=1,100)/) > 50
  dda = (/(J1,J1=1,100)/)

  IDS = MAXLOC(DDA,1, .not. mask)
  print *, ids ! expect 50
  END


The code in question is in gfc_conv_intrinsic_minmaxloc (trans-intrinsic.c):

  /* Remember where we are.  An offset must be added to the loop
 counter to obtain the required position.  */
  if (loop.temp_dim)
tmp = build_int_cst (gfc_array_index_type, 1);
  else
tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type,
   gfc_index_one_node, loop.from[0]);

All the failing cases I've seen so far happen in the (loop.temp_dim == true)
branch, and would be fixed by putting a zero there instead of the 1. But...
that's not all! It can also be something else than an off-by-one, it can be
off-by-more-than-that:

  REAL DDA(5:104)
  dda = (/(J1,J1=1,100)/)

  IDS = MAXLOC(DDA,1)
  print *, ids ! expect 100
  IDS = MAXLOC(DDA,1, (/(J1,J1=1,100)/) > 50)
  print *, ids ! expect 100

  END

gives 105 instead of 100 for the second call to MAXLOC. I'm not too sure what
is the correct approach, maybe something like (can't test right now):

Index: trans-intrinsic.c
===
--- trans-intrinsic.c   (revision 134439)
+++ trans-intrinsic.c   (working copy)
@@ -2171,11 +2171,11 @@

   /* Remember where we are.  An offset must be added to the loop
  counter to obtain the required position.  */
-  if (loop.temp_dim)
+  if (loop.from[0])
 tmp = build_int_cst (gfc_array_index_type, 1);
   else
-tmp =fold_build2 (MINUS_EXPR, gfc_array_index_type,
-gfc_index_one_node, loop.from[0]);
+tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type,
+  gfc_index_one_node, loop.from[0]);
   gfc_add_modify_expr (&block, offset, tmp);

   tmp = fold_build2 (PLUS_EXPR, TREE_TYPE (pos),

(the loop.temp_dim vs. loop.from[0] is important, the rest is whitespace
change).


-- 

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

[Bug other/36025] New: "cpu_set_t" not declared in "OS_Interface" compilation problem on alpha

[oliver at linux-kernel dot at]

Here are the last few lines of my build.log.

/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/./gcc/xgcc
-B/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/./gcc/
-B/usr/alpha-redhat-linux/bin/ -B/usr/alpha-redhat-linux/lib/ -isystem
/usr/alpha-redhat-linux/include -isystem /usr/alpha-redhat-linux/sys-include -c
-g -O2 -fPIC -mieee  -W -Wall -gnatpg  a-dynpri.adb -o a-dynpri.o
s-tasinf.ads:81:42: "cpu_set_t" not declared in "OS_Interface"
make[8]: *** [a-dynpri.o] Error 1
make[8]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/gcc/ada/rts'
make[7]: *** [gnatlib] Error 2
make[7]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/gcc/ada'
make[6]: *** [gnatlib-shared-default] Error 2
make[6]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/gcc/ada'
make[5]: *** [gnatlib-shared-dual] Error 2
make[5]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/gcc/ada'
make[4]: *** [gnatlib-shared] Error 2
make[4]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux/alpha-redhat-linux/libada'
make[2]: *** [all-target-libada] Error 2
make[2]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory
`/data/cvs/devel/gcc/gcc-4.3.0-20080416/obj-alpha-redhat-linux'
error: Bad exit status from /var/tmp/rpm-tmp.93998 (%build)

In case you need an account on an alpha, please don't hesitate to ask.


-- 
   Summary: "cpu_set_t" not declared in "OS_Interface" compilation
problem on alpha
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver at linux-kernel dot at
 GCC build triplet: alpha-redhat-linux
  GCC host triplet: alpha-redhat-linux
GCC target triplet: alpha-redhat-linux


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

[Bug c/36024] New: Incorrect function name in linking error

[ashutosh dot nema at nechclst dot in]

gcc compiler does not give the correct function name in error

test case::

struct abc
{
  int xx;
};

extern void *__nw__FUi (unsigned);
extern struct abc *__ct__3abcFv (struct abc *);

int
main (void)
{
  auto struct abc obj;
  __ct__3abcFv ((&obj));
  return (obj.xx);
}

struct abc *
__ct__3abcFv (struct abc *this)
{
  if ((this != ((struct abc *) 0))
  || ((this = ((struct abc *) (__nw__FUi (4U != ((struct abc *) 0)))
{
  (this->xx) = 1;
}
  return this;
}


output:
/tmp/cc00HPTT.o: In function `abc::__ct(void)':
tt2.c:(.text+0x3c): undefined reference to `operator new(unsigned int)'
collect2: ld returned 1 exit status

__ct function does not exists in the input test case.
why it is doing such


But when we change the name of function in the input program __ct__3abcFv to
any other name 
then it gives the correct function name in error message.


-- 
   Summary: Incorrect function name in linking error
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ashutosh dot nema at nechclst dot in


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

[Bug c/34389] -Wconversion produces wrong warning

[rainy6144 at gmail dot com]

--- Comment #9 from rainy6144 at gmail dot com  2008-04-23 07:20 ---
Does the patch also fix the warning for conditional expressions?  For example:

short f(int cond, short x, short y)
{
  return cond ? x : y;
}


-- 

rainy6144 at gmail dot com changed:

   What|Removed |Added

 CC||rainy6144 at gmail dot com


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