[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

[ilgb at livius dot net]

--- Comment #1 from ilgb at livius dot net  2008-02-02 08:11 ---
after upgrading to WinAVR-20071221 my C++ projects trigger the same warning
message.

for completeness, my sources look like:


// usb_user_device_descriptor
PROGMEM S_usb_device_descriptor usb_dev_desc =
  {
sizeof( usb_dev_desc ), DEVICE_DESCRIPTOR,
U_WORD( USB_SPECIFICATION ), DEVICE_CLASS,
DEVICE_SUB_CLASS, DEVICE_PROTOCOL, EP_CONTROL_LENGTH,
U_WORD( VENDOR_ID ),
U_WORD( PRODUCT_ID ),
U_WORD( RELEASE_NUMBER ), STRING_INDEX_MAN, STRING_INDEX_PROD,
STRING_INDEX_SN, NB_CONFIGURATION
  };

Liviu


-- 

ilgb at livius dot net changed:

   What|Removed |Added

 CC||ilgb at livius dot net


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

[Bug fortran/35036] illegal E format descriptor produces wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-02-02 08:28 
---
Here is a different view on this; from the standard:

For an internal value that is neither an IEEE infinity nor a NaN, the form of
the output field for a scale factor of zero is:

   [ ± ] [0].x1 x2 . . . xd exp

where:

± signifies a plus sign or a minus sign.

. signifies a decimal symbol (10.5).

x1 x2 . . . xd are the d most significant digits of the internal value
after rounding.

You will notice that the series of significant digits begins with x(1) going up
to x(d).  x(0) is not defined in the allowable output.  This makes sense since
this particular format has no significant digits to the left of the decimal
point and it is meaningless not to display at least 1 significant digit.

I would say then that the code is invalid.

Further, I don't think the discussion in the standard about the scaling factor
k is intended to say anything about the value of d, it is only speaking of what
to do under certain conditions of k relative to d.

Now if you look at the output from this simple test program:

  a = 1.e5
  write(*,'(E15.0)') a
  write(*,'(E15.1)') a
  write(*,'(E15.2)') a
  write(*,'(E15.3)') a
  write(*,'(E15.4)') a
  write(*,'(E15.5)') a
  write(*,'(E15.6)') a
  write(*,'(E15.7)') a
  write(*,'(E15.8)') a
  end
$ gfc pr35036.f 
$ ./a.out
 0.E+01
0.1E+06
   0.10E+06
  0.100E+06
 0.1000E+06
0.1E+06
   0.10E+06
  0.100E+06
 0.1000E+06

The pattern is clear and it breaks to nonsense for d=0.

The standard (F2003) also says: "10.6.1 (5) However, the processor shall not
produce asterisks if the field width is not exceeded when optional characters
are omitted.

I don't think this case is an issue of exceeding the width.  Therefore I think
a runtime error is appropriate.  Even better would be a compile time error as
well.


-- 


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

[Bug target/31388] ICE building libiberty multilib for mips16 multilibs

[rsandifo at gcc dot gnu dot org]

--- Comment #5 from rsandifo at gcc dot gnu dot org  2008-02-02 09:45 
---
Subject: Bug 31388

Author: rsandifo
Date: Sat Feb  2 09:44:21 2008
New Revision: 132066

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132066
Log:
gcc/
PR target/31388
* config/mips/mips.md (load_const_gp_): New insns.
* config/mips/mips.c (gen_load_const_gp): New function.
(mips_split_symbol): Avoid using or creating the MIPS16 GP
pseudo register if no_new_pseudos.
(mips16_gp_pseudo_reg): Use gen_load_const_gp.

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


-- 


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

[Bug target/35054] New: No documentation of #pragma push_macro("macro_name")

[dannysmith at users dot sourceforge dot net]

The new feature 

#pragma push_macro("macro_name") 
and 
#pragma pop_macro("macro_name") 

enabled by 

2007-03-30  Richard Henderson  <[EMAIL PROTECTED]>
Kai Tietz  <[EMAIL PROTECTED]>

* c-pragma.c (struct def_pragma_macro_value): New.
(struct def_pragma_macro): New.
(pushed_macro_table): New.
(dpm_hash, dpm_eq): New.
(handle_pragma_push_macro, handle_pragma_pop_macro): New.
(init_pragma): Install them.
* doc/tm.texi (HANDLE_PRAGMA_PUSH_POP_MACRO): New.

is not documented as a user extension in extend.texi


-- 
   Summary: No documentation of  #pragma push_macro("macro_name")
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net


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

[Bug target/34981] [4.2 Regression] Lazily-bound function called twice

[rsandifo at gcc dot gnu dot org]

--- Comment #4 from rsandifo at gcc dot gnu dot org  2008-02-02 09:56 
---
Subject: Bug 34981

Author: rsandifo
Date: Sat Feb  2 09:55:42 2008
New Revision: 132067

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132067
Log:
gcc/
PR target/34981
* config/mips/mips-protos.h (mips_expand_call): Return an rtx.
(build_mips16_call_stub): Likewise.
* config/mips/mips.h (FIRST_PSEUDO_REGISTER): Rename FAKE_CALL_REGNO
to GOT_VERSION_REGNUM.
(CALL_REALLY_USED_REGISTERS): Set the GOT_VERSION_REGNUM entry to 0.
(EPILOGUE_USES): Include GOT_VERSION_REGNUM if TARGET_ABICALLS.
* config/mips/mips.c (mips_emit_call_insn): New function.
(mips_call_tls_get_addr): Call mips_expand_call directly.
(mips_expand_call): Update the call to build_mips16_call_stub
and remove a redundant condition.  Assert that MIPS16 stubs do not
use lazy binding.  Use mips_emit_call_insn and return the call insn.
(override_options): Allow SImode for GOT_VERSION_REGNUM.
(build_mips16_call_stub): Use mips_emit_call_insn rather than
emit_call_insn.  Return the call insn or null.
(mips_avoid_hazard): Remove hazard_set handling.
(mips_extra_live_on_entry): Include GOT_VERSION_REGNUM if
TARGET_ABICALLS.
* config/mips/mips.md (UNSPEC_EH_RECEIVER): Rename to...
(UNSPEC_RESTORE_GP): ...this.
(UNSPEC_SET_GOT_VERSION, UNSPEC_UPDATE_GOT_VERSION): New constants.
(FAKE_CALL_REGNO): Rename to...
(GOT_VERSION_REGNUM): ...this.
(type): Add "ghost" value.  Add an associated insn reservation.
(hazard_set): Remove.
(exception_receiver): Rename to...
(restore_gp): ...this and update the unspec identifier accordingly.
(exception_receiver, nonlocal_got_receiver): New expanders.
(load_call): Use GOT_VERSION_REGNUM.  Don't set
FAKE_CALL_REGNO.  Remove hazard_set attribute.
(set_got_version, update_got_version): New patterns.

gcc/testsuite/
PR target/34981
* gcc.target/mips/lazy-binding-1.c: New test.
* gcc.target/mips/mips.exp (setup_mips_tests): Set mips_abi,
mips_forced_gp, mips_forced_no_abicalls, mips_forced_no_shared
and mips_forced_no_er.
(dg-mips-options): Avoid using -mips16 -mhard-float for ABIs
other than o32 and o64.  Avoid using -mabicalls with an implicit
-mabi=eabi.  Avoid using small data with -mabicalls.  Skip
-mabi=*, -G*, -mabicalls, -mshared and -mexplicit-relocs tests
if the multilib forces the an incompatible option.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.target/mips/lazy-binding-1.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/config/mips/mips-protos.h
branches/gcc-4_2-branch/gcc/config/mips/mips.c
branches/gcc-4_2-branch/gcc/config/mips/mips.h
branches/gcc-4_2-branch/gcc/config/mips/mips.md
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog
branches/gcc-4_2-branch/gcc/testsuite/gcc.target/mips/mips.exp


-- 


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

[Bug target/34900] [4.2 Regression] target mips64vrel-elf. Internal compiler error (in reload_cse_simplify_operands, at postreload.c:392) while building libiberty

[rsandifo at gcc dot gnu dot org]

--- Comment #6 from rsandifo at gcc dot gnu dot org  2008-02-02 10:02 
---
Subject: Bug 34900

Author: rsandifo
Date: Sat Feb  2 10:01:38 2008
New Revision: 132068

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132068
Log:
Add PR 34900 to CL for PR 31388

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog


-- 


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

[Bug target/31388] ICE building libiberty multilib for mips16 multilibs

[rsandifo at gcc dot gnu dot org]

--- Comment #6 from rsandifo at gcc dot gnu dot org  2008-02-02 10:02 
---
Subject: Bug 31388

Author: rsandifo
Date: Sat Feb  2 10:01:38 2008
New Revision: 132068

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132068
Log:
Add PR 34900 to CL for PR 31388

Modified:
branches/gcc-4_2-branch/gcc/ChangeLog


-- 


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

[Bug target/34981] [4.2 Regression] Lazily-bound function called twice

[rsandifo at gcc dot gnu dot org]

--- Comment #5 from rsandifo at gcc dot gnu dot org  2008-02-02 10:03 
---
Fixed on mainline and 4.2.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/34900] [4.2 Regression] target mips64vrel-elf. Internal compiler error (in reload_cse_simplify_operands, at postreload.c:392) while building libiberty

[rsandifo at gcc dot gnu dot org]

--- Comment #7 from rsandifo at gcc dot gnu dot org  2008-02-02 10:06 
---
Patch applied to 4.2 (labelled as PR31388


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug preprocessor/35055] New: missing path to finclude directory when compiling .F90 files

[hailijuan at gmail dot com]

testcase: (a.F90)
#include "omp_lib.h"

call omp_set_dynamic (.false.)
call omp_set_num_threads(4)

!$omp parallel
 print *, "t#:", omp_get_thread_num()
!$omp end parallel
end

#gfortran a.F90 -fopenmp
a.F90:1: error: omp_lib.h: No such file or directory

the file omp_lib.h is found in
/import/dr3/s10/gcc-4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.0/finclude.

"cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN" is invoked to
preprocess a.F90. the array cpp_include_defaults defined in cppdefault.c has to
add in ***/finclude/ and its data structure has to be refined to mark the
include is for fortran.


-- 
   Summary: missing path to finclude directory when compiling .F90
files
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com


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

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[dominiq at lps dot ens dot fr]

--- Comment #25 from dominiq at lps dot ens dot fr  2008-02-02 11:09 ---
>From comment #24:

> ... handling the large array constructors by building the array at run time 
> is obviously not fixed yet.

This can be done for

INTEGER, PARAMETER :: N=65535
INTEGER :: I(N)=(/(MOD(K,2),K=1,N)/)
INTEGER :: M(N)=(/(MOD(K,2),K=N,1,-1)/)
print *, M(N)

but not when I and M are PARAMETERs: if I am not mistaken PARAMETER defines
constants for the compiler, hence cannot be deferred to run time.  Note that
the above code compiles in few seconds while it takes several hundred seconds
with PARAMETER.

A short term solution could be to improve the error message when the 65535
limit is reached: "Initialization expression didn't reduce" does not point
clearly to this limit. An error (if correct?) such that "Array constructors
cannot have more than 65535 elements" will give a better diagnostic of what's
going wrong.


-- 


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

[Bug fortran/35036] illegal E format descriptor produces wrong output

[dominiq at lps dot ens dot fr]

--- Comment #12 from dominiq at lps dot ens dot fr  2008-02-02 11:13 ---
I agree that "If -d < k <= 0" is confusing when you don't specify k. However
you can remove the k and get "if -d<0", aka "if 0http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35036

[Bug middle-end/34882] g++: Internal error: Killed (program cc1plus)

[myway dot cn at gmail dot com]

--- Comment #7 from myway dot cn at gmail dot com  2008-02-02 12:06 ---
(In reply to comment #6)
> The initialize_command_download() exposes the usual memory-hungriness of GCC
> with repetitive C++ initializers.  We have plenty of bugreports with testcases
> for this, closing as invalid.  And yes, 32MB + 200MB swap will never make
> you happy with C++ and gcc.
> 

However, it's not the 1st time that i compiled rtorrent on NSLU2 Debian etch
platform.
Therefore, why this gcc version 4.2.3 cause this issues?


-- 


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #17 from belyshev at depni dot sinp dot msu dot ru  2008-02-02 
12:22 ---
And here are clean results for the same revision:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00099.html , which confirms
that patch from comment 13 causes many new failures.


-- 


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

[Bug middle-end/35056] New: [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

Current trunk ICEs in building libqt4:

g++-4.3 -O -o /dev/null -S style.cpp 
rendering/RenderStyle.h: In member function 'void
WebCore::RenderStyle::setOutlineStyle(WebCore::EBorderStyle, bool)':
rendering/RenderStyle.h:1570: internal compiler error: in copy_to_mode_reg, at
explow.c:621
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.3 Regression] ICE in copy_to_mode_reg, at
explow.c:621
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: critical
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-02 12:27 ---
Created an attachment (id=15076)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15076&action=view)
testcase (unincluded)


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-02 12:27 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.2.2
   Target Milestone|--- |4.3.0


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

[Bug bootstrap/35051] [4.3 Regression] Build machine requires GMP and MPFR for building cross-host gccs

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-02 12:31 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build
   Priority|P3  |P2


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

[Bug middle-end/35053] SSE2 testcase crashes

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-02 12:33 ---
_mm_store_ps stores four(!) float values at the destination which needs to be
16-byte aligned.


-- 

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

[Bug middle-end/35053] SSE2 testcase crashes

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-02 12:34 ---
I suppose you want _mm_store_ss, btw.


-- 


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

[Bug other/33702] [meta-bug] GCC 4.4 pending patches

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-02 12:52 ---
Add alias to this bug.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

  Alias||4.4pending


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

[Bug c/34985] Warning "defined but not used" despite __attribute__((__used__))

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-02-02 12:52 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00044.html

I miss the patch tracker :(


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
OtherBugsDependingO||33702
  nThis||
 AssignedTo|unassigned at gcc dot gnu   |manu at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Keywords||patch
   Last reconfirmed|2008-01-26 20:09:33 |2008-02-02 12:52:41
   date||


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

[Bug middle-end/17843] Warning not given for unreachable code in a switch

[aldot at gcc dot gnu dot org]

--- Comment #6 from aldot at gcc dot gnu dot org  2008-02-02 13:43 ---
Created an attachment (id=15077)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15077&action=view)
Emit warning for surplus case labels in a switch stmt with a boolean condition

The attached patchlet would warn about a superfluous default_label in a
switch_statement that uses a boolean as condition.
It does not burden VRP to emit this warning but checks in c-common.c instead.

gcc/ChangeLog
2008-02-02  Bernhard Fischer  

* c-common.c (record_surplus_node): New function.
(c_do_switch_warnings): Warn for surplus default label in switch
stmt.


-- 


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

[Bug middle-end/17843] Warning not given for unreachable code in a switch

[aldot at gcc dot gnu dot org]

--- Comment #7 from aldot at gcc dot gnu dot org  2008-02-02 13:44 ---
Reconfirm for 4.3.0 / 4.4.x


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |
   |patches/2008-   |
   |01/msg00149.html|
   Keywords||patch
   Last reconfirmed|2006-02-13 04:13:47 |2008-02-02 13:44:24
   date||


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

[Bug other/33702] [meta-bug] GCC 4.4 pending patches

[aldot at gcc dot gnu dot org]

--- Comment #2 from aldot at gcc dot gnu dot org  2008-02-02 13:46 ---
Add link to PR17843 -- Warning not given for unreachable code in a switch

In this case a boolean condition; Does not use (the already a bit convoluted)
VRP.


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu dot org
  BugsThisDependsOn||17843


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

[Bug libfortran/35001] shape for negative sizes

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-02-02 13:51 ---
Subject: Bug 35001

Author: tkoenig
Date: Sat Feb  2 13:50:55 2008
New Revision: 132070

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132070
Log:
2008-02-02  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/35001
* m4/shape.m4:  Return 0 for extents <= 0.
* generated/shape_i4.c:  Regenerated.
* generated/shape_i8.c:  Regenerated.
* generated/shape_i16.c:  Regenerated.

2008-02-02  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/35001
* gfortran.dg/shape_4.f90:  New test.

Fixed in regression-only mode by special dispense (see the PR).


Added:
trunk/gcc/testsuite/gfortran.dg/shape_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/shape_i16.c
trunk/libgfortran/generated/shape_i4.c
trunk/libgfortran/generated/shape_i8.c
trunk/libgfortran/m4/shape.m4


-- 


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

[Bug libfortran/35001] shape for negative sizes

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-02-02 13:51 ---
(In reply to comment #2)
> Thomas, this is OK to commit since it is fixing a wrong code bug, assuming you
> have regression tested. (Discussed with Richi on IRC.)

Yes, I had done so.

Commited to trunk.  Thanks!

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[matz at gcc dot gnu dot org]

--- Comment #25 from matz at gcc dot gnu dot org  2008-02-02 15:01 ---
Subject: Bug 35045

Author: matz
Date: Sat Feb  2 15:00:57 2008
New Revision: 132071

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132071
Log:
PR target/35045
* postreload-gcse.c (record_last_reg_set_info_regno): Renamed
from record_last_reg_set_info.
(record_last_reg_set_info): Take an RTX argument, iterate over all
constituent hardregs.
(record_last_set_info, record_opr_changes): Change calls to
new signature or to record_last_reg_set_info_regno.

* gcc.dg/pr35045.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr35045.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload-gcse.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35045] [4.3 Regression] gcc-4.3 generates wrong code on i386 with -O3

[matz at gcc dot gnu dot org]

--- Comment #26 from matz at gcc dot gnu dot org  2008-02-02 15:06 ---
Fixed in trunk.  Matthias: thanks for the hint with the bugnumber :-)


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

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

[olafvdspek at gmail dot com]

Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456930

With -O2 it calls bind with 0, without and with -O3 it works fine.
Asio is a C++ networking library.

$ g++ -I misc -lpthread t.cpp && strace ./a.out
...
bind(6, {sa_family=AF_INET, sin_port=htons(2711),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
...

$ g++ -I misc -O2 -lpthread t.cpp && strace ./a.out 
...
bind(6, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")},
16) = 0
...

http://downloads.sourceforge.net/asio/asio-0.3.9.tar.bz2?modtime=1197163255&big_mirror=0

#include 

class server
{
public:
server(asio::io_service&);
asio::ip::tcp::acceptor acceptor_;
};

server::server(asio::io_service& io_service):
acceptor_(io_service,
asio::ip::tcp::endpoint(asio::ip::tcp::v4(), 2711))
{
}

int main()
{
asio::io_service io_service;
server s(io_service);
return 0;
}

$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080127-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.0 20080127 (experimental) [trunk revision 131882] (Debian
4.3-20080127-1)


-- 
   Summary: Integer variable value lost due to optimizations?
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olafvdspek at gmail dot com
GCC target triplet: i486-linux-gnu


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-02 15:23 ---
Please provide preprocessed source of your testcase.  It is very likely
that asio::ip::tcp::endpoint is bogus.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

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

[olafvdspek at gmail dot com]

--- Comment #2 from olafvdspek at gmail dot com  2008-02-02 15:33 ---
Created an attachment (id=15078)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15078&action=view)
Preprocessor output (I hope)

I hope -E is the right option.


-- 


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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[hutchinsonandy at aim dot com]

--- Comment #28 from hutchinsonandy at aim dot com  2008-02-02 15:44 ---
The patch and suggestions on this are valid. However, memory moves  -
particular with base pointers, may require additional instruction to be added
to reach required displacments. Splitting such moves may well incur the
overhead per BYTE!

So we need to get the pointers sorted so that (for example) 4 separate QI bytes
is just as good as 1 access to 4 SI bytes.

As for other pattern removal YES!

The reason to change MOVE_MAX is not made clear. I understood this to control
the threshold for using movmem rather than inline RTL. movmem wins (in size) at
about 8+ bytes. Does it have another use related to this problem?


-- 

hutchinsonandy at aim dot com changed:

   What|Removed |Added

 CC||hutchinsonandy at aim dot
   ||com


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2008-02-02 15:52 ---
Reduced by hand:

% cat x.cc
enum EBorderStyle { bla = 1 };
template
inline bool compareEqual(const T& t, const U& u)
{
  return t == u;
}
struct S {
  unsigned m_style : 4;
};

void call (S *s, EBorderStyle v)
{
  if (!compareEqual(s->m_style, v))
s->m_style = v;
}

The problem is confusion between the bitmap type and promotion.  If you
rewrite the compare into a direct expression ("if (s->m_style != v) ...")
the error doesn't occur.  Anyway, as written this get's generated as
(004.gimple):

   D.1670;
  unsigned char D.1673;
  unsigned int D.1668;

  D.1670 = s->m_style;
  D.1668 = D.1670;
  D.1671 = compareEqual (&D.1668, &v);
  retval.0 = !D.1671;

Note how s->m_style gets copied first into a unsigned:4, then into an unsigned
temp, which is given to compareEqual.  v (the enum) stays as is.  This gets
further expanded into (from 130.final_cleanup):

:
  if (s->m_style != v)

I.e. no conversions anymore.  But if we look at the expression which is tried
to be expanded to RTL:

do_compare_and_jump (exp=0xb7cb9438, ...
(gdb) p debug_tree (exp)
  unit size 
   align 8 symtab 0 alias set -1 canonical type 0xb7d46f08
   precision 4
   min  max >
   arg 1 
unit size 

Note how the first argument has the bitfield type (4 bit precision) and
QImode, and the second argument is the enum type, which has SImode, precision
32 (but min/max being 0/1).

>From there everything goes down, because the RTL expander is not prepared
for compares of mismatching mode.  Simply noone checks if the arguments
have a different mode; it checks for VOIDmode of constants, and BLKmode, in
which case it also expects a size.  But if the mode is normal then it must
be the same for both operands.


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenther at suse dot de]

--- Comment #4 from rguenther at suse dot de  2008-02-02 15:57 ---
Subject: Re:  [4.3 Regression] ICE in copy_to_mode_reg,
 at explow.c:621

On Sat, 2 Feb 2008, matz at gcc dot gnu dot org wrote:

> --- Comment #3 from matz at gcc dot gnu dot org  2008-02-02 15:52 ---
> Reduced by hand:
> 
> % cat x.cc
> enum EBorderStyle { bla = 1 };
> template
> inline bool compareEqual(const T& t, const U& u)
> {
>   return t == u;
> }
> struct S {
>   unsigned m_style : 4;
> };
> 
> void call (S *s, EBorderStyle v)
> {
>   if (!compareEqual(s->m_style, v))
> s->m_style = v;
> }
> 
> The problem is confusion between the bitmap type and promotion.  If you
> rewrite the compare into a direct expression ("if (s->m_style != v) ...")
> the error doesn't occur.  Anyway, as written this get's generated as
> (004.gimple):
> 
>D.1670;
>   unsigned char D.1673;
>   unsigned int D.1668;
> 
>   D.1670 = s->m_style;
>   D.1668 = D.1670;

This is missing a conversion, type checking would complain.

Richard.


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-02 16:06 ---
>From the .original dump:

;; Function void call(S*, EBorderStyle) (_Z4callP1S12EBorderStyle)
;; enabled by -tree-original


<<< Unknown tree: if_stmt
  , (const EBorderStyle &) (const EBorderStyle
*) &v)>>
  >>
>>
   >>>
;

The TARGET_EXPR initializer already misses the conversion.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-02 16:06:33
   date||


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[matz at gcc dot gnu dot org]

--- Comment #6 from matz at gcc dot gnu dot org  2008-02-02 16:08 ---
(written before richis comment, essentially the same info)

The compare routine doesn't need to be a template to show the bug.  But it
needs to take reference parameters.  The difference is in the call.  E.g.
with this testcase:

% cat x.cc
enum EBorderStyle { bla = 1 };
inline bool compare_ref(const unsigned int &t, const EBorderStyle &u)
{ return t == u; }
inline bool compare_val(const unsigned int t, const EBorderStyle u)
{ return t == u; }
struct S {
  unsigned m_style : 4;
};
void call_ref (S *s, EBorderStyle v)
{ if (!compare_ref(s->m_style, v)) s->m_style = v; }
void call_val (S *s, EBorderStyle v)
{ if (!compare_val(s->m_style, v)) s->m_style = v; }

The bodies of the two compare routines is sensible (after all nothing
fancy happens as not bitfield types are involved there anymore):

bool compare_ref(const unsigned int&, const EBorderStyle&) (t, u)
{
  bool D.1655;
  unsigned int D.1656;
  EBorderStyle D.1657;

  D.1656 = *t;
  D.1657 = *u;
  D.1655 = D.1656 == D.1657;
  return D.1655;
}
bool compare_val(unsigned int, EBorderStyle) (t, u)
{
  bool D.1662;

  D.1662 = t == u;
  return D.1662;
}

But the difference in the call setup is revealing:

void call_ref(S*, EBorderStyle) (s, v)
   D.1672;
  unsigned int D.1670;
  ...
  D.1672 = s->m_style;
  D.1670 = D.1672;
  D.1673 = compare_ref (&D.1670, &v);
}

void call_val(S*, EBorderStyle) (s, v)
{
  ...
   D.1682;
  unsigned int D.1683;
  ...
  D.1682 = s->m_style;
  D.1683 = (unsigned int) D.1682;
  D.1684 = compare_val (D.1683, v);
}

Note how the call with the reference parameter copies the value from the 
bitfield into an unsigned temp without a cast, and the call by value copies
it into a unsigned temp with a cast.  That latter cast will stay there until
130.final_cleanup, and hence the compare instruction will be expanded
correctly.


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-02 16:15 ---
This

Index: tree.c
===
--- tree.c  (revision 132071)
+++ tree.c  (working copy)
@@ -417,6 +417,10 @@ build_target_expr_with_type (tree init, 
aggregate; there's no additional work to be done.  */
 return force_rvalue (init);

+  if (INTEGRAL_TYPE_P (type)
+  || POINTER_TYPE_P (type))
+init = fold_convert (type, init);
+
   return force_target_expr (type, init);
 }


fixes it.  It might be not the very best place for the fix though (and with
dependent arguments it might not be wise to call into the middle-end either).


-- 


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

[Bug middle-end/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-02-02 16:16 ---
The TARGET_EXPR is built via

#0  build4_stat (code=TARGET_EXPR, tt=0xb7ce6340, arg0=0xb7ce0160, 
arg1=0xb7ce10f0, arg2=0x0, arg3=0x0)
at /home/richard/src/trunk/gcc/tree.c:3207
#1  0x0825c48e in build_target_expr (decl=0xb7ce0160, value=0xb7ce10f0)
at /home/richard/src/trunk/gcc/cp/tree.c:262
#2  0x0825da09 in force_target_expr (type=0xb7ce6340, init=0xb7ce10f0)
at /home/richard/src/trunk/gcc/cp/tree.c:435
#3  0x0825d9b3 in build_target_expr_with_type (init=0xb7ce10f0, 
type=0xb7ce6340) at /home/richard/src/trunk/gcc/cp/tree.c:420
#4  0x080606dd in convert_like_real (convs=0x8e6968c, expr=0xb7ce10f0, 
fn=0xb7d689a0, argnum=0, inner=0, issue_conversion_warnings=1 '\001', 
c_cast_p=0 '\0') at /home/richard/src/trunk/gcc/cp/call.c:4510
#5  0x08063669 in build_over_call (cand=0x8e696d4, flags=3)
at /home/richard/src/trunk/gcc/cp/call.c:4996
#6  0x08059170 in build_new_function_call (fn=0xb7d6ca48, args=0xb7d6c9f4, 
koenig_p=1 '\001') at /home/richard/src/trunk/gcc/cp/call.c:2887
#7  0x0824ac2f in finish_call_expr (fn=0xb7d6ca48, args=0xb7d6c9f4, 
disallow_virtual=0 '\0', koenig_p=1 '\001')
at /home/richard/src/trunk/gcc/cp/semantics.c:1942


-- 


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

[Bug tree-optimization/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3

[hubicka at gcc dot gnu dot org]

--- Comment #12 from hubicka at gcc dot gnu dot org  2008-02-02 16:22 
---
Created an attachment (id=15079)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15079&action=view)
address accumulation patch

While working on PR17863 I wrote the attached patch to make fwprop to combine
code like:

a=base;
*a=something;
a++;
*a=something;
a++;
*a=something;
...

into

*base=something
a=base+1
*a=something
a=base+2
*a=something


I dropped it to vangelis and nightly tester shows gzip improvement 815->880.
Gzip internal loop is hand unrolled into similar form as shown above.
(the tester peaks in Jul 2005 with scores somewhat above 900). Since it gzip
results tends to be unstable it would be nice to know how this reproduce on
other targets/setups.

Honza


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-02-02 16:30 ---
The correct fix is probably here (convert_like_real):

if ((lvalue & clk_packed)
&& CLASS_TYPE_P (type)
&& !TYPE_HAS_TRIVIAL_INIT_REF (type))
  {
error ("cannot bind packed field %qE to %qT",
   expr, ref_type);
return error_mark_node;
  }
expr = build_target_expr_with_type (expr, type);

and call convert_like_real (convs->u.next, expr ... with the right mysterious
arguments before passing the initializer to build_target_expr_with_type.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |c++


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

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #26 from sgk at troutmask dot apl dot washington dot edu  
2008-02-02 16:38 ---
Subject: Re:  Implied do-loop in an initialization expression is broken

On Sat, Feb 02, 2008 at 11:09:36AM -, dominiq at lps dot ens dot fr wrote:
> 
> A short term solution could be to improve the error message when the 65535
> limit is reached: "Initialization expression didn't reduce" does not point
> clearly to this limit. An error (if correct?) such that "Array constructors
> cannot have more than 65535 elements" will give a better diagnostic of what's
> going wrong.
> 

65535 was arbitrarily chosen by me.  This value allowed the
fmlib package to compile and run.  65535 should actually be
spelled as 100 (or maybe even smaller).  Short term solutions
have the uncanny nature of becoming long term bandaids.
See PR 19925 for an example.

Erik suggested in comment #6 one possible solution to the
problem.  In the mailing list or IRC, Paul Brook suggested
that a CTOR/DTOR methods should be considered.


-- 


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

[Bug c/35058] New: -Werror= works only with some warnings

[michaelni at gmx dot at]

-Werror=declaration-after-statement and -Werror=pointer-arith
only generate warnings not errors. 
Example
-
void *a;

void *test(){
if(a=a) a++;
int x=5;
return a+x;
}

gcc-4.3 -Werror=declaration-after-statement -Werror=pointer-arith testX.c -c -o
testX


adding -Werror=parentheses generates an error as expected though
also interrestingly -fdiagnostics-show-option shows only [-Wparentheses] and
nothing for the other 2 warnings

Note, this issue has been seen on x86-32 and ppc


-- 
   Summary: -Werror= works only with some warnings
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michaelni at gmx dot at


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

[Bug fortran/35059] New: Seg fault when max constructor limit reached

[jvdelisle at gcc dot gnu dot org]

The following gives a segmentation fault with N > 65535.  This is taken from
PR19925 Comment #10.  I have the fix for the segfault.

INTEGER, PARAMETER :: N=10
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
INTEGER, PARAMETER :: M(N)=I(N:1:-1)
END


-- 
   Summary: Seg fault when max constructor limit reached
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: jvdelisle at gcc dot gnu dot org
ReportedBy: jvdelisle at gcc dot gnu dot org


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

[Bug fortran/35059] Seg fault when max constructor limit reached

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-02-02 17:36 
---
Created an attachment (id=15080)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15080&action=view)
Proposed patch to fix some segfaults

This patch avoids the seg fault for the test case in this PR as well as the
invalid code given in PR34828 Comment #10.  I will submit this when 4.4 opens.


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[matz at gcc dot gnu dot org]

--- Comment #10 from matz at gcc dot gnu dot org  2008-02-02 17:47 ---
A TARGET_EXPR has the following semantics:
(1) If it's a RHS of a MODIFY_STMT (or similar), i.e.:
   lhs = TARGET_EXPR
this is (for gimplifying) the same as
   lhs = init
except when TREE_TYPE(init) is void, in that case the init tree is
expected to magically set 'slot' when evaluated.
(2) If it's not the RHS of something, i.e. in a toplevel stmt for instance,
then this is equivalent to:
   slot = init
(again, except when 'init' has void type).

Let's ignore the case that 'init' has void type, then 'init' is an expression,
and the semantics of TARGET_EXPR are the same as
temp = init

This is only valid when
  useless_type_conversion(TREE_TYPE(temp), TREE_TYPE(init)) .
Hence I think for all TARGET_EXPRs created, for which init hasn't void type,
the above predicate has to hold.  I think this is best ensured in the lowest
functions which create TARGET_EXPR, not in the high-level users.

Hence I think the safest would be to modify build_target_expr directly,
with something like this:

Index: cp/tree.c
===
--- cp/tree.c   (Revision 132064)
+++ cp/tree.c   (Arbeitskopie)
@@ -259,6 +259,11 @@ build_target_expr (tree decl, tree value
 {
   tree t;

+  if (!VOID_TYPE_P (TREE_TYPE (value))
+  && TREE_TYPE (decl) != TREE_TYPE (value)
+  && !useless_type_conversion_p (TREE_TYPE (decl), TREE_TYPE (value)))
+value = fold_convert (TREE_TYPE (decl), value);
+
   t = build4 (TARGET_EXPR, TREE_TYPE (decl), decl, value,
  cxx_maybe_build_cleanup (decl), NULL_TREE);
   /* We always set TREE_SIDE_EFFECTS so that expand_expr does not


-- 


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2008-02-02 18:42 
---
Note that I think the FEs should not use the middle-end predicate but instead
use the more strict type equality as fold does.  But I'll leave that to the
FE maintainers to figure out what and where the best fix is for this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org


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

[Bug c/34947] [4.2 Regression] Clobbered float registers not popped

[vincent dot riviere at freesbee dot fr]

--- Comment #1 from vincent dot riviere at freesbee dot fr  2008-02-02 
19:14 ---
The bug is still here in the official 4.2.3


-- 

vincent dot riviere at freesbee dot fr changed:

   What|Removed |Added

   Severity|normal  |major
  Component|target  |c
  Known to fail||4.2.3
  Known to work||4.1.2
Summary|Clobbered float registers   |[4.2 Regression] Clobbered
   |not popped  |float registers not popped


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

[Bug fortran/35036] illegal E format descriptor produces wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2008-02-02 19:36 
---
Created an attachment (id=15081)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15081&action=view)
Proposed patch

This patch provides an error for precision (number of digits left of decimal
point) specified with E and D formats.  This is consistent with the Standards
and Sun f95.  It also gives an error if the scaling factor is out of acceptable
range.


-- 


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[tbm at cyrius dot com]

--- Comment #18 from tbm at cyrius dot com  2008-02-02 20:08 ---
I see regressions with the patch too.


-- 


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

[Bug c/34993] [4.1/4.2 regression] ICE with attribute for array with unknown bound

[rth at gcc dot gnu dot org]

--- Comment #5 from rth at gcc dot gnu dot org  2008-02-02 20:42 ---
Subject: Bug 34993

Author: rth
Date: Sat Feb  2 20:42:10 2008
New Revision: 132073

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132073
Log:
PR c/34993
* tree.c (build_type_attribute_qual_variant): Skip TYPE_DOMAIN
for unbounded arrays.

Added:
branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr34993.c
Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/tree.c


-- 


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

[Bug c/34993] [4.1/4.2 regression] ICE with attribute for array with unknown bound

[rth at gcc dot gnu dot org]

--- Comment #6 from rth at gcc dot gnu dot org  2008-02-02 20:43 ---
Fixed.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33661] template methods forget explicit local reg vars

[vincent dot riviere at freesbee dot fr]

--- Comment #2 from vincent dot riviere at freesbee dot fr  2008-02-02 
20:48 ---
Still fails in GCC release 4.2.3


-- 

vincent dot riviere at freesbee dot fr changed:

   What|Removed |Added

  Known to fail|3.3.3 4.1.0 4.3.0   |3.3.3 4.1.0 4.2.3 4.3.0


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

[Bug c/35058] -Werror= works only with some warnings

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2008-02-02 21:15 ---
Thanks for the report.

Any warning that does not show with -fdiagnostics-show-option is very likely to
not work with -Werror= and viceversa, so please report all of them that you
find.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT

[dominiq at lps dot ens dot fr]

--- Comment #29 from dominiq at lps dot ens dot fr  2008-02-02 21:31 ---
With the patch in http://gcc.gnu.org/ml/fortran/2008-02/msg6.html, I still
get an error for the test case in comment #25:

pr32760_2.f90:8.29:

allocate(s(4), stat=istat, source=t)
1
Error: Syntax error in ALLOCATE statement at (1)

Is this normal?


-- 


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

[Bug fortran/35036] illegal E format descriptor produces wrong output

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2008-02-03 00:06 
---
Created an attachment (id=15082)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15082&action=view)
Revised test case

This test case is updated with additional tests.


-- 


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

[Bug c++/35060] New: typeid(*).name() returns wrong values

[andry at inbox dot ru]

///
#include 
#include 

class _A12345 {
  virtual ~_A12345() {}
};

extern "C" {
  void foo() { }
  void foo2() { }
}

#define ClassName _A12345

int main() {
  printf("%s\n",typeid(ClassName).name());
  printf("%s\n",typeid(foo).name());
  printf("%s\n",typeid(foo2).name());
  return 0;
}
///

Output:
7_A12345
FvvE
FvvE

1. I think should be "_A12345" instead "7_A12345".
2. foo/foo2 is different types so names must have difference too.
3. extern "C" i think should turn off name mangling, but it isn't.


-- 
   Summary: typeid(*).name() returns wrong values
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andry at inbox dot ru
  GCC host triplet: i686-pc-cygwin


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

[Bug c++/35056] [4.3 Regression] ICE in copy_to_mode_reg, at explow.c:621

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2008-02-03 07:48 ---
In the FE usually no predicate is used, you just call fold_convert and it will
return the second argument if the types match, otherwise add NOP_EXPR or
whatever
is appropriate around it.
The question is just whether build_target_expr is the right spot to insert
the fold_convert, or whether it shouldn't be done in its callers.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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