[Bug fortran/36681] compiler error message with gfortran 4.3.1 but not with 4.2.1

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2008-07-01 08:22 ---
Very similar to, if not a dupe of, PR36590.


-- 


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

[Bug target/36669] Wrong versioning for __float128

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2008-07-01 08:56 
---
We cannot "fix" this after the fact.  And it's IMHO not worth it either.
We could add the symbol to GCC_4.3.0 as well and make that the default
though.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c/36684] New: [4.3 regression] compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

gcc-4.3.0 fails to compile with this message when compiling 
expect-5.43.0. gcc-4.1.3 can compile without fail.
They are both natively running on sh4 board.


   gcc -c  -I. -I. -I/usr/include/tcl-private/generic  
-DEXP_VERSION=\"5.43.0\" -DSCRIPTDIR=\"/usr/share/tcl8.5/expect5.43\"
-DEXECSCRIPTDIR=\"/usr/lib/tcl8.5/expect5.43\" -DTCL_DEBUGGER -DUSE_NON_CONST
-DSTTY_BIN=\"/bin/stty\" -O2 -g -mieee -O2 -g -mieee -pipe  -fPIC
-DDFLT_STTY="\"sane\""  Dbg.c -o shared/Dbg.o ; \
fi
Dbg.c: In function 'Dbg_Interactor':
Dbg.c:1071: error: unable to find a register to spill in class 'R0_REGS'
Dbg.c:1071: error: this is the insn:
(insn:HI 31 50 51 4 Dbg.c:1069 (set (mem/f/c/i:SI (plus:SI (reg/f:SI 3 r3
[186])(reg:SI 12 r12)) [22 interdata+0 S4 A32])
(reg/v/f:SI 6 r6 [orig:165 data ] [165])) 172 {movsi_ie}
(expr_list:REG_DEAD (reg/f:SI 3 r3 [186])
(expr_list:REG_DEAD (reg/v/f:SI 6 r6 [orig:165 data ] [165])
(nil
Dbg.c:1071: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccjGJhgH.out file, please attach this to
your bugreport.
make: *** [Dbg.o] Error 1

# /usr/bin/gcc -v
Using built-in specs.
Target: sh4-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--build=sh4-redhat-linux
Thread model: posix
gcc version 4.3.0 20080404 (Red Hat 4.3.0-6.fs1.1) (GCC)


-- 
   Summary: [4.3 regression] compile failure with message "unable to
find a register to spill in class 'R0_REGS'"
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: masaki dot chikama at gmail dot com
 GCC build triplet: sh4-redhat-linux
  GCC host triplet: sh4-redhat-linux
GCC target triplet: sh4-redhat-linux


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

[Bug c/36684] [4.3 regression] compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

--- Comment #1 from masaki dot chikama at gmail dot com  2008-07-01 09:34 
---
Created an attachment (id=15838)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15838&action=view)
ccOOu6ip.out


-- 


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

[Bug c/36684] [4.3 regression] compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

--- Comment #2 from masaki dot chikama at gmail dot com  2008-07-01 09:41 
---
Sorry.
"/tmp/ccjGJhgH.out" is another try's message.
Attached file(ccOOu6ip.out) are produced with same message.


-- 


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

[Bug middle-end/36684] [4.3 Regression] compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
Summary|[4.3 regression] compile|[4.3 Regression] compile
   |failure with message "unable|failure with message "unable
   |to find a register to spill |to find a register to spill
   |in class 'R0_REGS'" |in class 'R0_REGS'"
   Target Milestone|--- |4.3.2


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

[Bug c++/36685] New: clarify/diagnose use of weak constant

[algrant at acm dot org]

Consider this:

  __attribute__((weak)) extern int const K = 7;
  int f(void) { return K; }
  int a[K];

Assuming the combination of 'weak' and 'const' is legitimate
(and it seems useful enough to allow), the compiler should avoid
the constant-promotion optimization when generating f(), and
should fault a[].


-- 
   Summary: clarify/diagnose use of weak constant
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org


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

[Bug c++/36686] New: [4.3 regression] qt-4.3.4 compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

gcc-4.3.0 fails to compile with this message when compiling 
qt-4.3.4. gcc-4.1.3 can compile without fail.
They are both natively running on sh4 board.

The message is very similar with Bug #36684. They may have the same root cause.


g++ -c -include .pch/release-shared/QtGui -pipe -fno-exceptions -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -g -mieee
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
-DQT_44_API_QSQLQUERY_FINISH -DQT3_SUPPORT -DQT_MOC_COMPAT
-DQT_RASTER_IMAGEENGINE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA
-DQT_NO_STYLE_WINDOWSXP -DQ_INTERNAL_QAPP_SRC -DQT_NO_DEBUG -DQT_CORE_LIB
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I.
-I../../include/QtCore -I../../include/QtCore -I../../include
-I../../include/QtGui -I/usr/include/freetype2 -I../3rdparty/harfbuzz/src
-Idialogs -I.moc/release-shared -I/usr/X11R6/include -I.uic/release-shared -o
.obj/release-shared/qcolordialog.o dialogs/qcolordialog.cpp
In file included from dialogs/qcolordialog.cpp:1717:
dialogs/qcolordialog.cpp: In member function 'virtual QSize
QColorPicker::sizeHint() const':
dialogs/qcolordialog.cpp:834: error: unable to find a register to spill in
class 'R0_REGS'
dialogs/qcolordialog.cpp:834: error: this is the insn:
(insn:HI 25 53 26 2 dialogs/qcolordialog.cpp:833 (set (reg:SI 1 r1 [orig:178
pHeight ] [178])
(mem/c/i:SI (plus:SI (reg/f:SI 1 r1 [175])
(reg:SI 12 r12)) [11 pHeight+0 S4 A32])) 172 {movsi_ie}
(expr_list:REG_DEAD (reg/f:SI 1 r1 [175])
(nil)))
dialogs/qcolordialog.cpp:834: confused by earlier errors, bailing out
make[1]: *** [.obj/release-shared/qcolordialog.o] Error 1
make[1]: Leaving directory
`/builddir/build/BUILD/qt-x11-opensource-src-4.3.4/src/gui'


# /usr/bin/gcc -v
Using built-in specs.
Target: sh4-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--build=sh4-redhat-linux
Thread model: posix
gcc version 4.3.0 20080404 (Red Hat 4.3.0-6.fs1.1) (GCC)


-- 
   Summary: [4.3 regression] qt-4.3.4 compile failure with message
"unable to find a register to spill in class 'R0_REGS'"
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: masaki dot chikama at gmail dot com
 GCC build triplet: sh4-redhat-linux
  GCC host triplet: sh4-redhat-linux
GCC target triplet: sh4-redhat-linux


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

[Bug c++/36686] [4.3 regression] qt-4.3.4 compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

--- Comment #1 from masaki dot chikama at gmail dot com  2008-07-01 10:13 
---
Created an attachment (id=15839)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15839&action=view)
preprocessed file generated by adding -save-temps


-- 


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

[Bug c++/36685] clarify/diagnose use of weak constant

[algrant at acm dot org]

--- Comment #1 from algrant at acm dot org  2008-07-01 10:21 ---
Similar argument applies to __attribute__((visibility("default"))) .


-- 


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

[Bug tree-optimization/36666] [4.4 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2573

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-07-01 11:05 ---
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=3

[Bug tree-optimization/36666] [4.4 Regression] ICE in process_constraint, at tree-ssa-structalias.c:2573

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-07-01 11:06 ---
Subject: Bug 3

Author: rguenth
Date: Tue Jul  1 11:05:17 2008
New Revision: 137315

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

PR tree-optimization/3
* tree-ssa-structalias.c (get_constraint_for_1): Declare.
(get_constraint_exp_from_ssa_var): Split into ...
(get_constraint_exp_for_temp): ... this ...
(get_constraint_for_ssa_var): ... and that.
Return constraint expressions for all touched sub-fields
if the results address is not taken.
(process_constraint): Remove assertion that aggregate
assignments do not happen at this place.
(get_constraint_for_component_ref): Add address_p argument.
Return constraint expressions for all touched sub-fields
if the results address is not taken.
(do_deref): Use get_constraint_exp_for_temp.
(get_constraint_for_1): Rename from ...
(get_constraint_for): ... this.  Add the old function as
wrapper.
(do_structure_copy): Use get_constraint_for_1.

* gcc.c-torture/compile/pr3.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug c++/36685] clarify/diagnose use of weak constant

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2008-07-01 11:35 ---
Subject: Re:   New: clarify/diagnose use of weak constant

See the inconclusive discussion at 
 (the 
original message was the previous month), and bug 35501.


-- 


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

[Bug middle-end/36684] [4.3 Regression] compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug c++/36687] New: g++ can not compile dbcheck.cpp of MythTV

[danielk at cuymedia dot net]

Note this is the case with both the 0.21-fixes and trunk of mythtv, same file.
* the exact version of GCC;
gcc (Ubuntu 4.3.1-3ubuntu1) 4.3.1
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
* the system type;
Linux intrepid-builder64.kristjansson.com 2.6.24-19-xen #1 SMP Wed Jun 18
16:08:38 UTC 2008 x86_64 GNU/Linux
* the complete command line that triggers the bug;

svn co http://svn.mythtv.org/svn/branches/release-0-21-fixes/ ; cd
release-0-21-fixes ; ./configure ; cd libs ; qmake ; cd libmythtv ; qmake ; g++
-c -pipe -g -march=k8 -fomit-frame-pointer -O3 -Wall -Wno-switch
-Wpointer-arith -Wredundant-decls -Wno-non-virtual-dtor
-D__STDC_CONSTANT_MACROS -I/usr/include/kde/artsc -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/directfb
-D_REENTRANT -I/usr/include/freetype2 -D_REENTRANT -DPIC -fPIC  -DMMX
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DUSING_OSS
-DUSING_H264TOOLS -DUSING_DIRECTFB -DUSING_X11 -DUSING_XV -DUSING_XVMC
-DUSING_XVMCW -DUSING_XVMC_VLD -DUSING_OPENGL -DUSING_FRONTEND
-DUSING_FFMPEG_THREADS -DUSING_V4L -DUSING_LINUX_FIREWIRE -DUSING_FIREWIRE
-DUSING_LIBAVC_5_3 -DUSING_DBOX2 -DUSING_IPTV -DUSING_HDHOMERUN -DUSING_IVTV
-DUSING_DVB -DUSING_BACKEND -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED
-DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/default -I. -I/usr/local/include
-I/usr/include -I../.. -I.. -I. -I../libmyth -I../libavcodec -I../libavutil
-I../libmythmpeg2 -Idvbdev -Impeg -Iiptv
-I../libmythlivemedia/BasicUsageEnvironment/include
-I../libmythlivemedia/groupsock/include -I../libmythlivemedia/liveMedia/include
-I../libmythlivemedia/UsageEnvironment/include -I/usr/include/qt3
-I/usr/X11R6/include -I/usr/X11R6/include -o dbcheck.o dbcheck.cpp


NOTE: If you remove -g, the compile still fails. But if you replace -O3 with
-O0 it succeeds. Also -O1 fails and -O2 fails.

* the compiler output (error messages, warnings, etc.); and

{standard input}: Assembler messages:
{standard input}:11005: Warning: end of file not at end of a line; newline
inserted
{standard input}:12373: Error: unknown pseudo-op: `.ul'
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See  for instructions.
make: *** [dbcheck.o] Error 1

* the preprocessed file (*.i*) that triggers the bug, generated by
  adding -save-temps to the complete compilation command, or, in
  the case of a bug report for the GNAT front end, a complete set
  of source files (see below).

Will attach


-- 
   Summary: g++ can not compile dbcheck.cpp of MythTV
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danielk at cuymedia dot net


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

[Bug c++/36687] g++ can not compile dbcheck.cpp of MythTV

[danielk at cuymedia dot net]

--- Comment #1 from danielk at cuymedia dot net  2008-07-01 13:31 ---
Created an attachment (id=15840)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15840&action=view)
Preprocessor output for failing file

Note: I should also note memory consumption by gcc is very high when compiling
this file.


-- 


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

[Bug middle-end/34744] Memory leaks in compiler with empty program

[zadeck at naturalbridge dot com]

--- Comment #2 from zadeck at naturalbridge dot com  2008-07-01 13:53 
---
Fixed as revision 137284 and 137285.


-- 

zadeck at naturalbridge dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/34744] Memory leaks in compiler with empty program

[zadeck at gcc dot gnu dot org]

--- Comment #3 from zadeck at gcc dot gnu dot org  2008-07-01 13:57 ---
Subject: Bug 34744

Author: zadeck
Date: Tue Jul  1 13:56:28 2008
New Revision: 137318

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137318
Log:
Marked changelog entry with PR rtl-optimization/34744

Modified:
trunk/gcc/ChangeLog


-- 


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

[Bug c/36688] New: Incorrect struct assignments with nested const initializers

[holger dot hopp at sap dot com]

g++ 4.3 and higher produces incorrect struct assignments with nested
constant initializers. In the example, the assignment x = init_x
initializes the struct with zero's, not with {{1,2,3},0}.

gcc versions:
  gcc 4.3.2 (svn, 2008/07/01, rev. 137317)
  gcc 4.4.0 (svn, 2008/06/24)

  gcc 3.3.3 and gcc 4.1.2 (SuSE) are running fine.

systems:
  x86_64, ia64 (probably platform independent)

command line:
  g++ -O0 t.c  (occurs with and without optimizations)


preprocessed file:

typedef long unsigned int size_t;

extern "C" int memcmp (__const void *__s1, __const void *__s2, size_t __n)
 throw () __attribute__ ((__pure__)) __attribute__ ((__nonnull__ (1, 2)));

typedef struct
{
  long long a;
  long long b;
  long long c;
} t_bar;


typedef struct
{
  t_bar g;
  long long free[12];
}
t_foo;


static const t_bar init_y = {1,2,3};
static const t_foo init_x = {init_y,0};

int main ()
{
  t_foo x = init_x;
  return memcmp (&x, &init_x, sizeof(t_foo));
}


-- 
   Summary: Incorrect struct assignments with nested const
initializers
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/34744] Memory leaks in compiler with empty program

[zadeck at gcc dot gnu dot org]

--- Comment #4 from zadeck at gcc dot gnu dot org  2008-07-01 14:06 ---
Subject: Bug 34744

Author: zadeck
Date: Tue Jul  1 14:05:13 2008
New Revision: 137319

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137319
Log:
2008-07-01  Kenneth Zadeck <[EMAIL PROTECTED]>

PR rtl-optimization/34744
* df-scan.c (df_scan_free_ref_vec, df_scan_free_mws_vec): New
macros.
(df_scan_free_internal): Free data structures not
allocated in storage pools.
(df_mw_hardreg_chain_delete_eq_uses): Use df_scan_free_mws_vec.
(df_refs_add_to_chains): Use df_scan_free_ref_vec and 
df_scan_free_mws_vec.
* dse.c (dse_step6): Free offset_map_p and offset_map_n
unconditionally.
* ifcvt.c (cond_move_process_if_block): Free vectors on false
return.



Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/df-scan.c
branches/gcc-4_3-branch/gcc/dse.c
branches/gcc-4_3-branch/gcc/ifcvt.c


-- 


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

[Bug fortran/36689] New: PRINT and WRITE eat minus sign

[dennis dot wassel at googlemail dot com]

Funny things abound... Negative numbers show up as positive, which can be
pretty -let's say- irritating in computational applications :)

I've managed to boil this down to the following example

PROGRAM Minus

  implicit none
  integer :: N
  real, pointer, dimension(:) :: XP => NULL()

  N = 2
  allocate(XP(N))

  XP = +1.23
  print *, "pos X = ", XP
  XP = -1.23
  print *, "neg X = ", XP

  print *, "zero = ", XP+1.23

END PROGRAM Minus

which produces the following output on an OpenSolaris 11 machine (note the
additional space)

 pos X =1.230   1.230
 neg X =   1.2302  1.2302
 zero =0.000   0.000

gfortran about himself (or itself?):
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.3.1/configure --prefix=/usr/local/lang
--program-suffix=_4.3.1 --enable-64bit --with-as=/usr/local/bin/gnu-as
--with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.1 (GCC)

Any pointers?


-- 
   Summary: PRINT and WRITE eat minus sign
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dennis dot wassel at googlemail dot com
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug debug/36690] New: .debug_line first line is behind the first instruction

[jan dot kratochvil at redhat dot com]

So far -O0 code could be safely debugged.  With 4.3.1 and HEAD if you `break
func' in GDB the breakpoint can be missed despite the function got executed. 
The line number info is wrong and as GCC does not produce prologue-end GDB is
using the line number information to skip the prologue.

Version-Release number of selected component (if applicable):
gcc-4.3.1-3.x86_64 (Fedora 9, broken)
Fedora 8 was correct: gcc-4.1.2-33.x86_64
Verified as broken on:
GNU C (GCC) version 4.4.0 20080701 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-9), GMP version
4.2.2, MPFR version 2.3.0-p2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Steps to Reproduce:
cat >whilemain.c <:
int i;

void func (void)
{
  40047c:   55  push   %rbp
  40047d:   48 89 e5mov%rsp,%rbp
  400480:   eb 0a   jmp40048c 
  while (i == 1)
i = 0;
  400482:   c7 05 fc 03 20 00 00movl   $0x0,0x2003fc(%rip)#
600888 
  400489:   00 00 00 

gcc-4.1.2-33.x86_64 (Fedora 8):
00400468 :
int i;

void func (void)
{
  400468:   55  push   %rbp
  400469:   48 89 e5mov%rsp,%rbp
  while (i == 1)
  40046c:   eb 0a   jmp400478 
i = 0;
  40046e:   c7 05 fc 03 20 00 00movl   $0x0,0x2003fc(%rip)#
600874 
  400475:   00 00 00


-- 
   Summary: .debug_line first line is behind the first instruction
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/36387] [4.2/4.3 Regression] points-to variables not transitively clobbered

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-07-01 15:35 ---
This is fixed on the trunk.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.2.4 4.3.1 4.4.0   |4.2.4 4.3.1
  Known to work|4.1.2   |4.1.2 4.4.0
Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] points-
   |points-to variables not |to variables not
   |transitively clobbered  |transitively clobbered


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

[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2008-07-01 15:52 ---
I've also observed this problem (as causing a number of GDB testsuite
failures).

With both 4.2 and 4.3, the function prologue is followed by a jump,
the loop body, and then the test of the loop condition which the jump
jumps to.  The loop body has the correct line number, as does the
condition.  With 4.2, the jump has the same line number as the
condition, so that's the line number to which GDB assigns a breakpoint
on the function.  With 4.3, the jump insn does not have a line number
and GDB decides to use the line number of the loop body, and the GDB
tests fail.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-01 15:52:34
   date||
Summary|.debug_line first line is   |[4.3/4.4 Regression]
   |behind the first instruction|.debug_line first line is
   ||behind the first instruction
   Target Milestone|--- |4.3.2


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

Re: Template type bug

[Etienne Grossmann]

  Hello again,

a little addition to my previous post: In a non-main c++ file (say
A.cpp), I write the code

 template  int max (int x, int y); // OK
 template  double max (double x, double y); // Fails

in order to instantiate the template, so that the function "double
max(double,double)" be in the object file A.o.
With "int", this works, but this fails with "double" and this is why I
sent the bug report.

  I can also instantiate the templates by putting in A.cpp a function

  void instantiateMaxFunctions ()
  {

}


On Mon, Jun 30, 2008 at 9:41 PM, Etienne Grossmann <[EMAIL PROTECTED]> wrote:
>  Hello,
>
> I do not have a login to submit a bug via bugzilla, so I use the
> second method in http://gcc.gnu.org/bugs.html#where and attach all the
> required info.
>
> In short, compiling w/ g++-4.3
> ==
> template  Comparable max (Comparable x, Comparable y)
> {
>  return x >= y ? x : y;
> }
>
> template  int max (int x, int y); // OK
> template  double max (double x, double y); // Fails
>
> int main ()  { return 0;}
> ===
> results in "error: 'double' is not a valid type for a template
> constant parameter", which I believe is inappropriate here.
>
>  Is this a known bug? I found similar bugs:
> http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01159.html
> http://gcc.gnu.org/ml/gcc-bugs/2007-12/msg02358.html, but they don't
> quite match.
>
> Another question: in http://gcc.gnu.org/bugs.html#known, there are
> many references, e.g. "see [14.6]", but there is no
>  bibliography. What is the refered document? (If it is an online
> document, the page bugs.html could contain links, thus avoiding silly
> questions like this one)
>
>  Thanking you for making g++ available in the first place,
>
>  Etienne
>

Re: Template type bug

[Etienne Grossmann]

  Sorry for the incomplete previous mail, which was spuriously sent...

 Hello again,

a little addition to my previous post: In a non-main c++ file (say
A.cpp), I write the code

template  int max (int x, int y); // OK
template  double max (double x, double y); // Fails

in order to instantiate the template, so that the function "double
max(double,double)" be in the object file A.o.
With "int", this works, but this fails with "double" and this is why I
sent the bug report.

 I can also instantiate the templates by putting in A.cpp a function

 void instantiateMaxFunctions ()
 {
max((int)0,  (int)0);
max((double)0.0, (double)0.0);
 }

 and this seems to work. Is this a preferred way of instantiating a template?

  Best regards,

  Etienne

On Tue, Jul 1, 2008 at 9:14 AM, Etienne Grossmann <[EMAIL PROTECTED]> wrote:
>  Hello again,
>
> a little addition to my previous post: In a non-main c++ file (say
> A.cpp), I write the code
>
> template  int max (int x, int y); // OK
> template  double max (double x, double y); // Fails
>
> in order to instantiate the template, so that the function "double
> max(double,double)" be in the object file A.o.
> With "int", this works, but this fails with "double" and this is why I
> sent the bug report.
>
>  I can also instantiate the templates by putting in A.cpp a function
>
>  void instantiateMaxFunctions ()
>  {
>
> }
>
>
> On Mon, Jun 30, 2008 at 9:41 PM, Etienne Grossmann <[EMAIL PROTECTED]> wrote:
>>  Hello,
>>
>> I do not have a login to submit a bug via bugzilla, so I use the
>> second method in http://gcc.gnu.org/bugs.html#where and attach all the
>> required info.
>>
>> In short, compiling w/ g++-4.3
>> ==
>> template  Comparable max (Comparable x, Comparable y)
>> {
>>  return x >= y ? x : y;
>> }
>>
>> template  int max (int x, int y); // OK
>> template  double max (double x, double y); // Fails
>>
>> int main ()  { return 0;}
>> ===
>> results in "error: 'double' is not a valid type for a template
>> constant parameter", which I believe is inappropriate here.
>>
>>  Is this a known bug? I found similar bugs:
>> http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01159.html
>> http://gcc.gnu.org/ml/gcc-bugs/2007-12/msg02358.html, but they don't
>> quite match.
>>
>> Another question: in http://gcc.gnu.org/bugs.html#known, there are
>> many references, e.g. "see [14.6]", but there is no
>>  bibliography. What is the refered document? (If it is an online
>> document, the page bugs.html could contain links, thus avoiding silly
>> questions like this one)
>>
>>  Thanking you for making g++ available in the first place,
>>
>>  Etienne
>>
>

[Bug other/31754] Include column number along line in error messages main.cpp:5:38

[dseketel at redhat dot com]

--- Comment #14 from dseketel at redhat dot com  2008-07-01 16:29 ---
Hello,

Just a quick comment on this bug.

I think that in the example you gave, gcc (at the least 4.3.0 version) is
giving a correct column location.

The expression gcc is complaining about is:

"a +- b".

That expression is normally valid, an can be re-written as a + -b (like in 2 +
-3).
In that case, the '-' is called an "unary minus" operator.

In your case, the reason why gcc is complaining is because 'b' is of type
pointer. And you cannot apply the "unary minus" operator to a pointer.

So gcc complains about the _operand_, saying the operand is of the wrong type.
That is why gcc is referering to the operand, instead of refering to the '-'.

On the other hand, it is notorious that gcc does not display extremely accurate
column numbers in error message. Hopefully, that situation can get better with
the patches attached above.


-- 


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

[Bug fortran/36689] PRINT and WRITE eat minus sign

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-07-01 18:06 ---
Not that it helps much, but on x86-64-linux I cannot reproduce this using GCC
4.1, 4.2, 4.3.1 and 4.4.0(of today). Though I agree that the bug is irritating.


-- 


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

[Bug fortran/35423] Implement OpenMP workshare

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-07-01 18:08 ---
First patch: http://gcc.gnu.org/ml/fortran/2008-06/msg00281.html


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug fortran/36670] Missing compile-time checks on sum and product

[tkoenig at gcc dot gnu dot org]

-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-01 19:14:18
   date||


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

[Bug target/36613] [4.1/4.2/4.3/4.4 Regression] likely codegen bug

[matz at gcc dot gnu dot org]

--- Comment #7 from matz at gcc dot gnu dot org  2008-07-01 19:17 ---
Blaeh.  The bug is in code that is there since the dawn of revision control,
under a comment that starts with "... This is tricky ..." and ends with
"I am not sure whether the algorithm here is always right ...".

One thing after another.  The problem is in insn 15 (with Jakubs testcase),
that effectively is:
   p58 <- p63 << p63:QI
It so happens that p63 is allocated to $edx and p58 to $ecx.  This is all
fine and would result in such insn:  %ecx = %edx << %dl

Then find_reloads comes and determines that the insn as is is invalid:
1) The output and first input have to match and
2) the second input needs to be in

So, it generates the first reload to make op0 and op1 match.
  in = inreg = (reg:SI dx)
  out = outreg = (reg:SI cx)
  inmode = outmode = SImode
  class = GENERAL_REGS
  type = RELOAD_OTHER
perfectly fine.  find_reloads will also already set reg_rtx (i.e. the register
that is used to carry out the reload) to (reg:SI cx), also quite fine and
correct.

Then it tries to generate another reload to fit the "c" constraint for operand
2:
  in = (subreg:QI (reg:SI dx))
  out = 0
  inmode = QImode
  class = CREG
  type = RELOAD_FOR_INPUT
Fairly early push_reload will substitute in (still a SUBREG) with the real
hardreg: in = (reg:QI dx).  Then it tries to find a mergable reload, and
indeed finds the first one.  That is also correct, the classes overlap,
the already assigned reg_rtx is member of that class (CREG) the types of
reloads are okay and so on.

Okay, so we don't generate a second reload for this operand, but simply reuse
the first one, so we have to merge the info of this to-be reload with the one
we have already.  That for instance would widen the existing mode if our new
reload would be wider.  See push_reload around line 1369 for what exactly
that merging does.  Among the things it does, it also overwrites .in:

   if (in != 0) {
 ...
 rld[i].in = in;
 rld[i].in_reg = in_reg;
   }

This might look strange, but in itself is okay.  It looks strange, because
our reload now looks like:
  in = inreg = (reg:QI dx)
  out = outreg = (reg:SI cx)
  inmode = outmode = SImode
  class = CREG
  type = RELOAD_OTHER
  reg_rtx = (reg:SI cx)

Note in particular that the .in reg is a QImode register, while the inmode
(and outmode) are still SImode.  This in itself is still not incorrect,
if this reload would be emitted as a SImode register move (from dx to cx),
as requested by the modes of this reload all would work.

I.e. the .in (and hence .out) registers are not to be used as real register
references, but merely as container for the hardreg _numbers_ we want to use.

Now, if we're going to emit this reload we go over do_input_reload,
and right at the beginning we have this:

  [ here old = rl->in; ]
  if (old && reg_rtx)
{
  enum machine_mode mode;
  /* Determine the mode to reload in.
 This is very tricky because we have three to choose from.
  ...
 I am not sure whether the algorithm here is always right,
 but it does the right things in those cases.  */
  mode = GET_MODE (old);
  if (mode == VOIDmode)
mode = rl->inmode;

So, it determines the mode _from the .in member_ by default, and only uses
the mode from the reload when that one is a constant.  Argh!  This means we
are now emitting a QImode move only loading %cl from %dl, whereas we would
need to load all of %ecx from %edx.  We emit this wrong reload insn, which
then later get's removed because we already have another reload %cl <- %dl
in the basic block before this one, which we are inheriting then.  This just
confuses the analysis somewhat, but the problem really is this too narrow
reload.
This code originally comes from do_input_reload, which in turn has it from
emit_reload_insns, and had this comment already in r120 of reload1.c .

I see basically two ways to fix this:
1) make push_reload "merge" also the .in member, instead of just overwriting
   it.  By merging I mean that if rld.in and in are both registers (in which
   case they have the same numbers already, as that is checked by
   find_reusable_reload) that leave in the larger of the two.  Same for
   .out.

2) Change do_input_reload (and also do_output_reload) to listen
   to inmode and outmode first, before looking at the mode of .in.
   The comment above this looks scary and lists some problematic cases, but
   given it's age I'm not at all sure if these indeed are still a problem.
   I actually think that inmode and outmode are currently the most precise
   descriptions of what this reload is about, unlike .in and .out whose
   significance lies more or less in the reg number only.

(2) might be the harder change, as it would require also reinterpreting
anything in .in or .out in the mode, in case they don't match.

I checked that (1) fixes the testcase, maybe I'm regstrapping that, it's the
simpler change.


-- 


http://gcc.gnu.org/bugzilla/

[Bug fortran/36683] -fbounds-check failure for allocated array and spread

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||34670
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-07-01 19:21:45
   date||


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

[Bug target/36622] 4.3.1 failed to compile gcse.c file.

[imam dot toufique at intel dot com]

--- Comment #17 from imam dot toufique at intel dot com  2008-07-01 19:26 
---
(In reply to comment #16)
> (In reply to comment #15)
> > I did:  
> > 
> > >svn co http://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch/ gcc-4.3
> > 
> > I hope I got the correct copy there, unless I did some wrong.  
> > 
> > if you have any suggestions on how to pick the right file, I am open to it.
> > thanks.
> It works for me on the sources I just got from SVN. Did you start from the
> clean  build directory?
> BTW: The file include/ansidecl.h is correct, but please check if your build
> process is using it to build md5.o.

Hi,

I found the issue and fixed that issue.

When will 4.3.2 be released for the mainstream?  I noticed it is 'pre-release'
right now.

Thanks
-Imam


-- 


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

[Bug fortran/36689] PRINT and WRITE eat minus sign

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-07-01 19:32 
---
Do you see the problem if XP is not declared a pointer?


-- 


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

[Bug target/36622] 4.3.1 failed to compile gcse.c file.

[imam dot toufique at intel dot com]

--- Comment #18 from imam dot toufique at intel dot com  2008-07-01 21:17 
---
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > I did:  
> > > 
> > > >svn co http://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch/ gcc-4.3
> > > 
> > > I hope I got the correct copy there, unless I did some wrong.  
> > > 
> > > if you have any suggestions on how to pick the right file, I am open to 
> > > it.
> > > thanks.
> > It works for me on the sources I just got from SVN. Did you start from the
> > clean  build directory?
> > BTW: The file include/ansidecl.h is correct, but please check if your build
> > process is using it to build md5.o.
> Hi,
> I found the issue and fixed that issue.
> When will 4.3.2 be released for the mainstream?  I noticed it is 'pre-release'
> right now.
> Thanks
> -Imam

-

Hi,

I am having an issue building libgcc.so now with this.

I am trying to use binutils 2.18 for this build, but during the libgcc build
state, I am getting an error below:

/usr/pkgs/gcc/4.3.2/i686-pc-linux-gnu/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
gmake[3]: *** [libgcc_s.so] Error 1


I am not sure why I am getting this, it looks like somewhat glibc related.  I
have done the same build successfuly in SuSE Linux Ent. Server 9 64-bit.  

Here is what the libgcc linking part where the error shows up:

/usr/pkgs/build/gcc/4.3.2/i686_linux26/gccbuild/./gcc/xgcc
-B/usr/pkgs/build/gcc/4.3.2/i686_linux26/gccbuild/./gcc/
-B/usr/pkgs/build/gcc/4.3.2/i686-pc-linux-gnu/bin/
-B/usr/pkgs/build/gcc/4.3.2/i686-pc-linux-gnu/lib/ -isystem
/usr/pkgs/build/gcc/4.3.2/i686-pc-linux-gnu/include -isystem
/usr/pkgs/build/gcc/4.3.2/i686-pc-linux-gnu/sys-include -O2  -O2 -g -O2 -fPIC
-I/usr/pkgs/libmpfr/2.3.0/include -L/usr/pkgs/libmpfr/2.3.0/lib
-I/usr/pkgs/libgmp/4.2.2/include -L/usr/pkgs/libgmp/4.2.2/lib 
-I/usr/pkgs/gcc/4.3.2/include -L/usr/pkgs/gcc/4.3.2/lib
-L/usr/pkgs/gcc/4.3.2/lib
-Wl,--rpath=/usr/pkgs/libmpfr/2.3.0/lib:/usr/pkgs/libgmp/4.2.2/lib:/usr/pkgs/gcc/4.3.2/lib
  -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o
./libgcc_s.so.1.tmp -g -fkeep-inline-functions -B./ _muldi3_s.o _negdi2_s.o
_lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o
_mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o
_ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o
_popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o
_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o
_fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o
_umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o
unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o
-lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f
./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
/usr/pkgs/gcc/4.3.2/i686-pc-linux-gnu/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
gmake[3]: *** [libgcc_s.so] Error 1

---
for binutils 'ld', here is the ldd output:

ldd /usr/pkgs/gcc/4.3.2/i686-pc-linux-gnu/bin/ld
linux-gate.so.1 =>  (0xe000)
libc.so.6 => /lib/tls/libc.so.6 (0x4003)
/lib/ld-linux.so.2 (0x4000)

is there anything I am doing wrong, or does gcc 4.3.2 have a specific binutils
requirement that I need to follow?

Please help!

Thanks


-- 


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

[Bug c/36691] New: wrong value left in induction variable

[regehr at cs dot utah dot edu]

This is seen using svn 137327 on Ubuntu Feisty.  I believe 0 is the correct
result.

[EMAIL PROTECTED] tmp35]$ current-gcc -O0 -fwrapv small.c -o small
[EMAIL PROTECTED] tmp35]$ ./small
0
[EMAIL PROTECTED] tmp35]$ current-gcc -O1 -fwrapv small.c -o small
[EMAIL PROTECTED] tmp35]$ ./small
255

[EMAIL PROTECTED] tmp35]$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080701 (experimental) (GCC) 

[EMAIL PROTECTED] tmp35]$ cat small.c

#include 

unsigned char g_5;

void func_1 (void);
void func_1 (void)
{
  for (g_5 = -7; g_5 >= 4; g_5 -= 5);
}

int main (void)
{
  func_1 ();
  printf ("%d\n", g_5);
  return 0;
}


-- 
   Summary: wrong value left in induction variable
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/36689] PRINT and WRITE eat minus sign

[dennis dot wassel at googlemail dot com]

--- Comment #3 from dennis dot wassel at googlemail dot com  2008-07-01 
22:55 ---
(In reply to comment #1)
> Not that it helps much, but on x86-64-linux I cannot reproduce this using GCC
> 4.1, 4.2, 4.3.1 and 4.4.0(of today). Though I agree that the bug is
> irritating.

Same with me, works like a treat on x86-linux with 4.3.1.


(In reply to comment #2)
> Do you see the problem if XP is not declared a pointer?

The problem seems to remain the same, regardless of the type of array of XP,
that is allocatable or fixed-size (compile-time).
Stupid I didn't check this earlier...


-- 


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

[Bug target/36684] [4.3/4.4 Regression] spill failure for class 'R0_REGS' on sh4 with -fPIC -O2

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2008-07-01 23:59 ---
A reduced testcase:

typedef int (proc) (int *interp, void *data);
typedef struct
{
  void *func;
  void *data;
} InterStruct;

extern InterStruct simple;
extern int simple_interactor ();
static proc *interactor = simple_interactor;


InterStruct Interactor(void *interp, proc inter_proc)
{
  InterStruct tmp = simple;
  interactor = (inter_proc ? inter_proc : simple_interactor);
  return tmp;
}


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
   GCC host triplet|sh4-redhat-linux|
 GCC target triplet|sh4-redhat-linux|sh4-*-linux
   Keywords||ice-on-valid-code
  Known to fail||4.3.1 4.4.0
  Known to work||4.1.3 4.2.4
   Last reconfirmed|-00-00 00:00:00 |2008-07-01 23:59:06
   date||
Summary|[4.3 Regression] compile|[4.3/4.4 Regression] spill
   |failure with message "unable|failure for class 'R0_REGS'
   |to find a register to spill |on sh4 with -fPIC -O2
   |in class 'R0_REGS'" |


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

[Bug target/36686] [4.3 regression] qt-4.3.4 compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[kkojima at gcc dot gnu dot org]

--- Comment #2 from kkojima at gcc dot gnu dot org  2008-07-02 00:20 ---
Could you please send the testcase without using precompiled headers?
See http://gcc.gnu.org/bugs.html#pch.

I also suspect this is a duplicate of PR36684.  Does -fno-schedule-insns
get rid of this error?


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING
  Component|c++ |target
   GCC host triplet|sh4-redhat-linux|
 GCC target triplet|sh4-redhat-linux|sh4-*-linux


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

[Bug c/36692] New: _Complex __float128 doesn't work

[hjl dot tools at gmail dot com]

[EMAIL PROTECTED] floa128-3]$ cat x.c
__float128
bar (__float128 x)
{
  return x;
}

_Complex  __float128
foo (_Complex __float128 x)
{
  return x;
}
[EMAIL PROTECTED] floa128-3]$ make x.s
/export/build/gnu/gcc-float128/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-float128/build-x86_64-linux/gcc/ -m32 -O2  -S -o x.s
x.c
x.c:8: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘foo’
make: *** [x.s] Error 1
[EMAIL PROTECTED] floa128-3]$


-- 
   Summary: _Complex  __float128 doesn't work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c/36692] _Complex __float128 doesn't work

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-02 00:44 ---
__float128 is a typedef.


-- 


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

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[BlanchardJ at ieee dot org]

--- Comment #3 from BlanchardJ at ieee dot org  2008-07-02 00:59 ---
(In reply to comment #2)
> Subject: Re:  gcc fails to build on Solaris x86 - it
>  forgets the locations of libmpfr
> 
> pinskia at gcc dot gnu dot org wrote:
> > --- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-10 08:52 
> > ---
> > Your configure line should not have LD_LIBRARY_PATH set.
> >
> > Also this works for me ...
> >
> >
> >   
> 
> 
> Can you tell me what I should set? Previous versions have worked with 
> far less messing around with flags to configure. If you can suggest a 
> set of flags which will work, I will try that.
> 

The error you get mean that the dynamic linker cannot find the required dynamic
library in this case libmpfr.so.1. You must add the installation path of mpfr
and gmp to the dynamic linker search path using the crle command.

Assuming that gmp and mpfr are installed in usr/local/lib/ then the following
command should take care of the problem.

**CAREFUL changes made with crle are immediate and if done incorrectly the
dynamic linker will stop working and Solaris won't boot anymore**

crle -u -l /usr/local/lib


-- 

BlanchardJ at ieee dot org changed:

   What|Removed |Added

 CC||BlanchardJ at ieee dot org


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

[Bug c/36692] _Complex __float128 doesn't work

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-07-02 01:25 ---
__float128 is a fundamental scalar type in x86-64 psABI, similar to float.


-- 


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

[Bug c/36692] _Complex __float128 doesn't work

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-07-02 02:04 ---
Not internally in GCC :).


-- 


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

[Bug fortran/34546] Incorrect array identified in out of bounds runtime error

[terry at chem dot gu dot se]

--- Comment #2 from terry at chem dot gu dot se  2008-07-02 02:10 ---
A gentle reminder:  This problem still exists as of 4.3.2 20080626.

(At least a compile-time warning is generated for Daniel's testcase.  If that
1000 index is an integer variable, however, the compile-time warning goes away
and the bounds check still indicates the wrong array.)


-- 


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

[Bug target/36686] [4.3 regression] qt-4.3.4 compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

--- Comment #3 from masaki dot chikama at gmail dot com  2008-07-02 03:14 
---
>Could you please send the testcase without using precompiled headers?
Do you mean that I should redo without "-include .pch/release-shared/QtGui" ?
I'll attach in next post.

>Does -fno-schedule-insns get rid of this error?
Yes. It passed without failure.
Is this a workaround or right fix ?


-- 


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #19 from hjl dot tools at gmail dot com  2008-07-02 03:15 
---
This patch

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

makes all TF symbols with version GCC_4.3.0 while keeping the old
version.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #20 from hjl dot tools at gmail dot com  2008-07-02 03:17 
---
Created an attachment (id=15841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15841&action=view)
A testcase

bash-3.2$ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash-3.2$ make clean
rm -f *.o float128-1 float128-2 float128-3 float128-4 float128-5 float128-6
bash-3.2$ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash-3.2$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -shared-libgccfloat128-1.c 
 -o float128-1
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -shared-libgccfloat128-2.c 
 -o float128-2
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -shared-libgccfloat128-3.c 
 -o float128-3
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -shared-libgccfloat128-4.c 
 -o float128-4
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -shared-libgccfloat128-5.c 
 -o float128-5
m/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -shared-libgccfloat128-6.c 
 -o float128-6
export LD_LIBRARY_PATH=/export/build/gnu/gcc/build-x86_64-linux/gcc; \
for e in float128-1 float128-2 float128-3 float128-4 float128-5
float128-6; do \
  echo $e: && ./$e; \
done
float128-1:
float128-2:
float128-3:
float128-4:
afloat128-5:
float128-6:
bash-3.2$ make old
for e in float128-1 float128-2 float128-3 float128-4 float128-5 float128-6; do
\
  echo $e: && ./$e; \
done
float128-1:
./float128-1: relocation error: ./float128-1: symbol __divtc3, version
GCC_4.3.0 not defined in file libgcc_s.so.1 with link time reference
float128-2:
./float128-2: relocation error: ./float128-2: symbol __multc3, version
GCC_4.3.0 not defined in file libgcc_s.so.1 with link time reference
float128-3:
./float128-3: relocation error: ./float128-3: symbol __powitf2, version
GCC_4.3.0 not defined in file libgcc_s.so.1 with link time reference
float128-4:
./float128-4: relocation error: ./float128-4: symbol __gttf2, version GCC_4.3.0
not defined in file libgcc_s.so.1 with link time reference
float128-5:
./float128-5: relocation error: ./float128-5: symbol __lttf2, version GCC_4.3.0
not defined in file libgcc_s.so.1 with link time reference
float128-6:
./float128-6: relocation error: ./float128-6: symbol __netf2, version GCC_4.3.0
not defined in file libgcc_s.so.1 with link time reference
make: [old] Error 127 (ignored)
bash-3.2$ make clean
rm -f *.o float128-1 float128-2 float128-3 float128-4 float128-5 float128-6
bash-3.2$ make CC=gcc
gcc -shared-libgccfloat128-1.c   -o float128-1
gcc -shared-libgccfloat128-2.c   -o float128-2
gcc -shared-libgccfloat128-3.c   -o float128-3
gcc -shared-libgccfloat128-4.c   -o float128-4
gcc -shared-libgccfloat128-5.c   -o float128-5
gcc -shared-libgccfloat128-6.c   -o float128-6
export LD_LIBRARY_PATH=/export/build/gnu/gcc/build-x86_64-linux/gcc; \
for e in float128-1 float128-2 float128-3 float128-4 float128-5
float128-6; do \
  echo $e: && ./$e; \
done
float128-1:
float128-2:
float128-3:
float128-4:
float128-5:
float128-6:
bash-3.2$ make old
for e in float128-1 float128-2 float128-3 float128-4 float128-5 float128-6; do
\
  echo $e: && ./$e; \
done
float128-1:
float128-2:
float128-3:
float128-4:
float128-5:
float128-6:
bash-3.2$ 


-- 


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

[Bug target/36686] [4.3 regression] qt-4.3.4 compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

--- Comment #4 from masaki dot chikama at gmail dot com  2008-07-02 03:20 
---
Created an attachment (id=15842)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15842&action=view)
preprocessed file without precompiled headers

gzipped beacuse plain text file's size is 1.5MB


-- 


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

[Bug target/36686] [4.3 regression] qt-4.3.4 compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2008-07-02 03:47 ---
Thanks for the updated testcase.  I've confirmed that this PR is
a duplicate of PR36684 as you suggested.

> Is this a workaround or right fix ?

SH backend enables first insn scheduling pass for SH4 when
the estimated R0 register pressure is low.  PR36684 reveals that
it doesn't work well for PIC which will make many implicit R0 uses.
It seems that there is no easy way to compute accurate R0 register
pressure in that case.  Also this optimization doesn't make much
difference in performance for such case.  So disabling it for PIC
would be a reasonable fix, I guess.  I'll prepare such patch for
PR36684.


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


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Keywords||ice-on-valid-code
  Known to fail||4.3.1 4.4.0
 Resolution||DUPLICATE


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

[Bug target/36684] [4.3/4.4 Regression] spill failure for class 'R0_REGS' on sh4 with -fPIC -O2

[kkojima at gcc dot gnu dot org]

--- Comment #4 from kkojima at gcc dot gnu dot org  2008-07-02 03:47 ---
*** Bug 36686 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/36684] [4.3/4.4 Regression] spill failure for class 'R0_REGS' on sh4 with -fPIC -O2

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2008-07-02 03:50 ---
SH backend enables insn scheduling before reload for SH4 when
the estimated R0 register pressure is low.  This PR reveals
that it doesn't work well for PIC which will make many implicit
R0 uses.  It seems that there is no easy way to compute accurate
R0 register pressure in that case.  I'm testing the patch below.

--- ORIG/trunk/gcc/config/sh/sh.h   2008-05-23 07:30:02.0 +0900
+++ INTEST/trunk/gcc/config/sh/sh.h 2008-07-02 08:41:42.0 +0900
@@ -712,8 +712,8 @@ do {   
\
 to the pressure on R0.  */ \
   /* Enable sched1 for SH4; ready queue will be reordered by   \
 the target hooks when pressure is high. We can not do this for \
-SH3 and lower as they give spill failures for R0.  */  \
-  if (!TARGET_HARD_SH4)\
+PIC, SH3 and lower as they give spill failures for R0.  */ \
+  if (!TARGET_HARD_SH4 || flag_pic)   
\
 flag_schedule_insns = 0;   \
   /* ??? Current exception handling places basic block boundaries  \
 after call_insns.  It causes the high pressure on R0 and gives \


-- 


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

[Bug target/36669] Wrong versioning for __float128

[hjl dot tools at gmail dot com]

--- Comment #21 from hjl dot tools at gmail dot com  2008-07-02 03:52 
---
(In reply to comment #19)
> This patch
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00071.html
> 
> makes all TF symbols with version GCC_4.3.0 while keeping the old
> version.
> 

With this patch, on Linux/x86-64, I got

[EMAIL PROTECTED] gcc]$ diff -up
../gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libgcc/libgcc.map
build-x86_64-linux/x86_64-unknown-linux-gnu/libgcc
--- ../gcc-4.3/build-x86_64-linux/x86_64-unknown-linux-gnu/libgcc/libgcc.map  
2008-05-05 15:47:08.0 -0700
+++ build-x86_64-linux/x86_64-unknown-linux-gnu/libgcc/libgcc.map  
2008-07-01 18:33:29.0 -0700
@@ -124,14 +124,19 @@ GCC_4.2.0 {
 } GCC_4.0.0;
 GCC_4.3.0 {
   global:
+   __multc3;
__unordtf2;
+   __divtc3;
__emutls_get_address;
__subtf3;
+   __netf2;
__trunctfxf2;
__fixunstfti;
__fixunstfdi;
__fixtfti;
__fixtfdi;
+   __gttf2;
+   __powitf2;
__trunctfdf2;
__getf2;
__extendsftf2;
@@ -139,6 +144,7 @@ GCC_4.3.0 {
__floatsitf;
__negtf2;
__bswapdi2;
+   __lttf2;
__addtf3;
__floatunditf;
__floatditf;
[EMAIL PROTECTED] gcc]$

On Linux/ia32, I got

[EMAIL PROTECTED] gcc]$ diff -up
../gcc-4.3/build-i686-linux/i686-pc-linux-gnu/libgcc/libgcc.map
build-i686-linux/i686-pc-linux-gnu/libgcc
--- ../gcc-4.3/build-i686-linux/i686-pc-linux-gnu/libgcc/libgcc.map
2008-05-05 15:55:10.0 -0700
+++ build-i686-linux/i686-pc-linux-gnu/libgcc/libgcc.map2008-07-01
18:43:06.0 -0700
@@ -119,3 +119,36 @@ GCC_4.3.0 {
__bswapdi2;
__emutls_get_address;
 } GCC_4.2.0;
+GCC_4.4.0 {
+  global:
+   __divtc3;
+   __fixtfdi;
+   __multc3;
+   __addtf3;
+   __trunctfxf2;
+   __extenddftf2;
+   __subtf3;
+   __eqtf2;
+   __trunctfsf2;
+   __floatditf;
+   __powitf2;
+   __getf2;
+   __floatsitf;
+   __fixunstfsi;
+   __gttf2;
+   __extendsftf2;
+   __floatunditf;
+   __trunctfdf2;
+   __letf2;
+   __negtf2;
+   __fabsq;
+   __unordtf2;
+   __floatunsitf;
+   __lttf2;
+   __divtf3;
+   __fixunstfdi;
+   __fixtfsi;
+   __netf2;
+   __multf3;
+   __copysignq;
+} GCC_4.3.0;
[EMAIL PROTECTED] gcc]$

On Linux/ia64, I got

[EMAIL PROTECTED] gcc]$ diff -up
../gcc-4.3/build-ia64-linux/ia64-unknown-linux-gnu/libgcc/libgcc.map
build-ia64-linux/ia64-unknown-linux-gnu/libgcc
[EMAIL PROTECTED] gcc]$


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-07-02 03:59 
---
Subject: Bug 36676

Author: jvdelisle
Date: Wed Jul  2 03:58:57 2008
New Revision: 137334

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

PR fortran/36676
* io/list_read.c (find_nml_name): Use eat_separator instead of
eat_line.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:02 
---
Subject: Bug 36676

Author: jvdelisle
Date: Wed Jul  2 04:01:57 2008
New Revision: 137335

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

PR fortran/36676
* gfortran.dg/namelist_51.f90: New test.

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


-- 


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

[Bug target/36686] [4.3 regression] qt-4.3.4 compile failure with message "unable to find a register to spill in class 'R0_REGS'"

[masaki dot chikama at gmail dot com]

--- Comment #6 from masaki dot chikama at gmail dot com  2008-07-02 04:06 
---
Thank you.
I'll learn more about background of this problem 
along with your comment.


-- 


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

[Bug libfortran/36546] Namelist error with tab following a comma and newline

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:45 
---
Subject: Bug 36546

Author: jvdelisle
Date: Wed Jul  2 04:44:21 2008
New Revision: 137336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137336
Log:
2008-07-01  Jerry DeLisle  <[EMAIL PROTECTED]

PR fortran/36676
PR fortran/36657
PR fortran/36546
Backport from trunk.
* io/list_read.c (find_nml_name): Use unget_char before eat_separator.
(read_character): Check for '!' along with separators.
(eat_separator): Add tab character to condition for looping past
whitespace.

Modified:
branches/gcc-4_3-branch/libgfortran/ChangeLog
branches/gcc-4_3-branch/libgfortran/io/list_read.c


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:45 
---
Subject: Bug 36676

Author: jvdelisle
Date: Wed Jul  2 04:44:21 2008
New Revision: 137336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137336
Log:
2008-07-01  Jerry DeLisle  <[EMAIL PROTECTED]

PR fortran/36676
PR fortran/36657
PR fortran/36546
Backport from trunk.
* io/list_read.c (find_nml_name): Use unget_char before eat_separator.
(read_character): Check for '!' along with separators.
(eat_separator): Add tab character to condition for looping past
whitespace.

Modified:
branches/gcc-4_3-branch/libgfortran/ChangeLog
branches/gcc-4_3-branch/libgfortran/io/list_read.c


-- 


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

[Bug libfortran/36657] Namelist reading bug with string constant immediately followed by comment

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:45 
---
Subject: Bug 36657

Author: jvdelisle
Date: Wed Jul  2 04:44:21 2008
New Revision: 137336

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137336
Log:
2008-07-01  Jerry DeLisle  <[EMAIL PROTECTED]

PR fortran/36676
PR fortran/36657
PR fortran/36546
Backport from trunk.
* io/list_read.c (find_nml_name): Use unget_char before eat_separator.
(read_character): Check for '!' along with separators.
(eat_separator): Add tab character to condition for looping past
whitespace.

Modified:
branches/gcc-4_3-branch/libgfortran/ChangeLog
branches/gcc-4_3-branch/libgfortran/io/list_read.c


-- 


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

[Bug libfortran/36657] Namelist reading bug with string constant immediately followed by comment

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:53 
---
Subject: Bug 36657

Author: jvdelisle
Date: Wed Jul  2 04:52:47 2008
New Revision: 137337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137337
Log:
2008-07-01  Jerry DeLisle  <[EMAIL PROTECTED]

PR fortran/36676
PR fortran/36657
PR fortran/36546
PR fortran/36538
* gfortran.dg/namelist_50.f90
* gfortran.dg/namelist_51.f90
* gfortran.dg/namelist_48.f90
* gfortran.dg/namelist_49.f90

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_48.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_49.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_50.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_51.f90
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:53 
---
Subject: Bug 36676

Author: jvdelisle
Date: Wed Jul  2 04:52:47 2008
New Revision: 137337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137337
Log:
2008-07-01  Jerry DeLisle  <[EMAIL PROTECTED]

PR fortran/36676
PR fortran/36657
PR fortran/36546
PR fortran/36538
* gfortran.dg/namelist_50.f90
* gfortran.dg/namelist_51.f90
* gfortran.dg/namelist_48.f90
* gfortran.dg/namelist_49.f90

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_48.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_49.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_50.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_51.f90
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/36546] Namelist error with tab following a comma and newline

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:53 
---
Subject: Bug 36546

Author: jvdelisle
Date: Wed Jul  2 04:52:47 2008
New Revision: 137337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137337
Log:
2008-07-01  Jerry DeLisle  <[EMAIL PROTECTED]

PR fortran/36676
PR fortran/36657
PR fortran/36546
PR fortran/36538
* gfortran.dg/namelist_50.f90
* gfortran.dg/namelist_51.f90
* gfortran.dg/namelist_48.f90
* gfortran.dg/namelist_49.f90

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_48.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_49.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_50.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_51.f90
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/36538] namelist failure with tabs preceding object name

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-07-02 04:53 
---
Subject: Bug 36538

Author: jvdelisle
Date: Wed Jul  2 04:52:47 2008
New Revision: 137337

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137337
Log:
2008-07-01  Jerry DeLisle  <[EMAIL PROTECTED]

PR fortran/36676
PR fortran/36657
PR fortran/36546
PR fortran/36538
* gfortran.dg/namelist_50.f90
* gfortran.dg/namelist_51.f90
* gfortran.dg/namelist_48.f90
* gfortran.dg/namelist_49.f90

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_48.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_49.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_50.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_51.f90
Modified:
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/34546] Incorrect array identified in out of bounds runtime error

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-07-02 05:06 
---
Currently 4.4 is giving:

$ gfc bounds.f90 
bounds.f90:6.31:

write(*,*) JTEJ(0,1000,:) * pT(1000,:)
  1
Warning: Array reference at (1) is out of bounds (1000 < 1) in dimension 1

I am not sure which patch did this, but I doubt it will be backported to 4.3


-- 


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

[Bug fortran/34546] Incorrect array identified in out of bounds runtime error

[terry at chem dot gu dot se]

--- Comment #4 from terry at chem dot gu dot se  2008-07-02 05:11 ---
(In reply to comment #3)
> I am not sure which patch did this, but I doubt it will be backported to 4.3


It already is in 4.3.  ;-)  As I said earlier, that warning is produced, but
easy to make go away with

integer::n ... n=1000 ... pT(n,:)

at the appropriate places.  Mangled runtime error message remains.


-- 


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

[Bug fortran/36676] Namelist Comments Problems

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-07-02 05:15 
---
Fixed on trunk and 4.3


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/36657] Namelist reading bug with string constant immediately followed by comment

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-07-02 05:18 
---
Fixed on Trunk and 4.3


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libfortran/36546] Namelist error with tab following a comma and newline

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-07-02 05:20 
---
Fixed on trunk and 4.3


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/36341] MATMUL: Bounds check missing (run time)

[tkoenig at gcc dot gnu dot org]

--- Comment #13 from tkoenig at gcc dot gnu dot org  2008-07-02 06:54 
---
Fixed for compile-time.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|MATMUL: Bounds check missing|MATMUL: Bounds check missing
   |(run time & compile time)   |(run time)


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

[Bug c/36692] _Complex __float128 doesn't work

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-07-02 06:57 ---
(In reply to comment #0)

> _Complex  __float128
> foo (_Complex __float128 x)
> {
>   return x;
> }

"typedef _Complex float __attribute__((mode(TC))) _Complex128" will work.

BTW: You also can't have "unsigned __int128", no matter how __int128 is defined
internally in gcc.


-- 


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