date:20110410

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

2011-04-10 Thread jb at gcc dot gnu.org

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

--- Comment #4 from Janne Blomqvist  2011-04-10 08:36:24 
UTC ---
(In reply to comment #3)
> Does any of the Fortran edit descriptors require, or for that matter allow,
> this kind of "shortest decimal representation" output?

Well, the obvious(?) answer is the various descriptors with 0 width.

[Bug driver/47547] [4.5 Regression] WHOPR, can't use /dev/null as an output file

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.5.3   |4.6.0

--- Comment #8 from Richard Guenther  2011-04-10 
10:16:13 UTC ---
Fixed for 4.6.

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

2011-04-10 Thread thenlich at users dot sourceforge.net

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

--- Comment #5 from Thomas Henlich  
2011-04-10 10:19:47 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Does any of the Fortran edit descriptors require, or for that matter allow,
> > this kind of "shortest decimal representation" output?
> 
> Well, the obvious(?) answer is the various descriptors with 0 width.

Not quite:

Since we're not talking about the shortest width (w) but the smallest number of
decimal digits in the fraction (d), only those descriptors where we can select
"a processor-dependent reasonable value for d" can be "shortened":

That would be list-directed and G0 (but not G0.d).

For all others the algorithm is still useful if we append zeros to fill the
required width: it is better to print 0.300 than 0.296

I'm still not sure where the Fortran standard says "a processor-dependent
reasonable value for d" that includes a "processor-dependent reasonable value
for d which also depends on the internal value to be printed" because that
would mess up tabular aligment for printing. This might be a feature users rely
on.

[Bug lto/48538] New: GCC build fails with -flto in BOOT_CFLAGS

2011-04-10 Thread jafb at tinet dot org

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

   Summary: GCC build fails with -flto in BOOT_CFLAGS
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@tinet.org


I'm trying to build gcc with some nonstandard options and it fails.
The error looks to be a bug in lto.
I'm compiling the sources in gcc-4.6.0.tar.bz2 (the full bundle).
My OS is Fedora 14 linux x86_64, with all packages updated to latest versions.
Some libraries are not the right version, so I compiled the following:

gmp-4.3.2
ppl-0.11.2
polylib-5.22.5
cloog-ppl-0.15.11

My configuration is:
../gcc/configure --enable-threads --with-arch=corei7 --with-tune=corei7
--with-fpmath=sse --enable-__cxa_atexit --enable-indirect-function
--enable-languages=c,c++,java,lto,objc,obj-c++,fortran,ada,go
--enable-libgcj-multifile --enable-java-home --with-arch-directory=x86_64
--enable-aot-compile-rpm --enable-browser-plugin --with-x
--enable-java-awt=gtk,xlib --enable-gtk-cairo --with-gmp=/usr/local
--with-ppl=/usr/local --with-cloog=/usr/local

I'm building with the following options:
make BOOT_CFLAGS='-O3 -march=corei7 -flto' profiledbootstrap

The error I get is the following:
/usr/local/src/gccbuild/./prev-gcc/xgcc -B/usr/local/src/gccbuild/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-static-libgcc
-static-libstdc++ -static-libgcc  -o gnat1 ada/b_gnat1.o ada/adadecode.o
ada/adaint.o ada/cstreams.o ada/cio.o ada/targtyps.o ada/decl.o ada/misc.o
ada/utils.o ada/utils2.o ada/trans.o ada/cuintp.o ada/argv.o ada/raise.o
ada/init.o ada/tracebak.o ada/initialize.o ada/env.o ada/a-charac.o
ada/a-chlat1.o ada/a-elchha.o ada/a-except.o ada/a-ioexce.o ada/ada.o ada/ali.o
ada/alloc.o ada/aspects.o ada/atree.o ada/butil.o ada/casing.o ada/checks.o
ada/comperr.o ada/csets.o ada/cstand.o ada/debug.o ada/debug_a.o ada/einfo.o
ada/elists.o ada/err_vars.o ada/errout.o ada/erroutc.o ada/eval_fat.o
ada/exp_aggr.o ada/exp_atag.o ada/exp_attr.o ada/exp_cg.o ada/exp_ch11.o
ada/exp_ch12.o ada/exp_ch13.o ada/exp_ch2.o ada/exp_ch3.o ada/exp_ch4.o
ada/exp_ch5.o ada/exp_ch6.o ada/exp_ch7.o ada/exp_ch8.o ada/exp_ch9.o
ada/exp_code.o ada/exp_dbug.o ada/exp_disp.o ada/exp_dist.o ada/exp_fixd.o
ada/exp_imgv.o ada/exp_intr.o ada/exp_pakd.o ada/exp_prag.o ada/exp_sel.o
ada/exp_smem.o ada/exp_strm.o ada/exp_tss.o ada/exp_util.o ada/exp_vfpt.o
ada/expander.o ada/fmap.o ada/fname-uf.o ada/fname.o ada/freeze.o
ada/frontend.o ada/g-byorma.o ada/g-hesora.o ada/g-htable.o ada/g-spchge.o
ada/g-speche.o ada/g-u3spch.o ada/get_scos.o ada/get_targ.o ada/gnat.o
ada/gnatvsn.o ada/hlo.o ada/hostparm.o ada/impunit.o ada/inline.o
ada/interfac.o ada/itypes.o ada/krunch.o ada/layout.o ada/lib-load.o
ada/lib-util.o ada/lib-writ.o ada/lib-xref.o ada/lib.o ada/live.o
ada/namet-sp.o ada/namet.o ada/nlists.o ada/nmake.o ada/opt.o ada/osint-c.o
ada/osint.o ada/output.o ada/par.o ada/par_sco.o ada/prep.o ada/prepcomp.o
ada/put_scos.o ada/repinfo.o ada/restrict.o ada/rident.o ada/rtsfind.o
ada/s-addope.o ada/s-assert.o ada/s-bitops.o ada/s-carun8.o ada/s-casuti.o
ada/s-conca2.o ada/s-conca3.o ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o
ada/s-conca7.o ada/s-conca8.o ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o
ada/s-except.o ada/s-exctab.o ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o
ada/s-mastop.o ada/s-memory.o ada/s-os_lib.o ada/s-parame.o ada/s-purexc.o
ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o ada/s-sopco4.o
ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o ada/s-strcom.o
ada/s-strhas.o ada/s-string.o ada/s-strops.o ada/s-traceb.o ada/s-traent.o
ada/s-unstyp.o ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o
ada/scans.o ada/scil_ll.o ada/scn.o ada/scng.o ada/scos.o ada/sdefault.o
ada/seh_init.o ada/sem.o ada/sem_aggr.o ada/sem_attr.o ada/sem_aux.o
ada/sem_case.o ada/sem_cat.o ada/sem_ch10.o ada/sem_ch11.o ada/sem_ch12.o
ada/sem_ch13.o ada/sem_ch2.o ada/sem_ch3.o ada/sem_ch4.o ada/sem_ch5.o
ada/sem_ch6.o ada/sem_ch7.o ada/sem_ch8.o ada/sem_ch9.o ada/sem_disp.o
ada/sem_dist.o ada/sem_elab.o ada/sem_elim.o ada/sem_eval.o ada/sem_intr.o
ada/sem_mech.o ada/sem_prag.o ada/sem_res.o ada/sem_scil.o ada/sem_smem.o
ada/sem_type.o ada/sem_util.o ada/sem_vfpt.o ada/sem_warn.o ada/sinfo-cn.o
ada/sinfo.o ada/sinput-d.o ada/sinput-l.o ada/sinput.o ada/snames.o
ada/sprint.o ada/stand.o ada/stringt.o ada/style.o ada/styleg.o ada/stylesw.o
ada/switch-c.o ada/switch.o ada/system.o ada/table.o ada/targext.o
ada/targparm.o ada/tbuild.o ada/tree_gen.o ada/tree_in.o ada/tree_io.o
ada/treepr.o ada/treeprs.o ada/ttypes.o ada/types.o ada/uintp.o ada/uname.o
ada/urealp.o ada/usage.o ada/validsw.o ada/widechar.o

[Bug tree-optimization/44336] [4.4/4.5 Regression] ICE: verify_ssa failed: SSA_NAME_DEF_STMT is wrong with -fipa-struct-reorg -fwhole-program

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #4 from Richard Guenther  2011-04-10 
10:23:49 UTC ---
struct-reorg has finally been removed.

[Bug target/44290] [4.5 regression] __naked attribute is broken

2011-04-10 Thread rguenth at gcc dot gnu.org

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

--- Comment #32 from Richard Guenther  2011-04-10 
10:27:30 UTC ---
Backporting regression fixes is generally fine and does not require explicit
approval (given that the patches do not need significant changes).

[Bug c++/42687] [4.4/4.5/4.6/4.7 Regression] The prevention of ADL with the help of parentheses doesn't work

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/47976] [4.5/4.6/4.7 Regression] Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|fortran |middle-end
  Known to work||4.5.2
Summary|[4.5 Regression] Recent |[4.5/4.6/4.7 Regression]
   |gfortran.dg/actual_array_co |Recent
   |nstructor_3.f90 regression  |gfortran.dg/actual_array_co
   |on arm-linux-gnueabi|nstructor_3.f90 regression
   ||on arm-linux-gnueabi

--- Comment #7 from Richard Guenther  2011-04-10 
10:36:37 UTC ---
A wrong-code regression on the branch for a primary taget.  P1.

Bernd, can you at least investigate?  Thanks.

Can someone check the status on the 4.6 and 4.7 branch?

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/48090] [4.5 Regression] gcc 4.5.2 miscompilation when building on arm

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.10 10:41:58
Version|unknown |4.5.2
 Ever Confirmed|0   |1

--- Comment #10 from Richard Guenther  2011-04-10 
10:41:58 UTC ---
(In reply to comment #9)
> I confirm that backporting r159644 and r159683 make things work. From comment
> 8, I guess that the bug is still there and that one can still hit it sooner or
> later, right  ? (btw, amazing job)

It probably papers over it as you guessed.

This bug lacks proper analysis.

[Bug middle-end/48124] [4.3/4.4/4.5/4.6/4.7 Regression] likely wrong code bug

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2

[Bug tree-optimization/48172] [4.5/4.6/4.7 Regression] incorrect vectorization of loop in GCC 4.5.* with -O3

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/48181] [4.5/4.6/4.7 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/48189] [4.3/4.4/4.5/4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #2 from Richard Guenther  2011-04-10 
10:44:21 UTC ---
Honza, ping?

[Bug rtl-optimization/48235] [4.5/4.6 Regression] ICE: SIGSEGV in has_dependence_p (sel-sched-ir.c:3263) with -fselective-scheduling2 and custom flags

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug preprocessor/48248] [4.5 Regression] Wrong error message location when compiling preprocessed code

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug driver/48306] [4.3/4.4/4.5/4.6/4.7 Regression] presence of gcc subdir with . in PATH causes breakdown

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/48389] [4.5/4.6 Regression] ICE: in make_edges, at cfgbuild.c:319 with -mtune=pentiumpro

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/48418] [4.5/4.6/4.7 Regression] Bit shift operator >>=

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/48446] [4.3/4.4/4.5/4.6 Regression] internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/48035] [4.4/4.5 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes

2011-04-10 Thread rguenth at gcc dot gnu.org

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P1  |P2
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

[Bug lto/48538] GCC build fails with -flto in BOOT_CFLAGS

2011-04-10 Thread rguenth at gcc dot gnu.org

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

--- Comment #1 from Richard Guenther  2011-04-10 
10:51:05 UTC ---
You should not merely use -flto in BOOT_CFLAGS, that will fail anyway.  Instead
use --with-build-config=bootstrap-lto.

[Bug objc/48539] New: Missing warning when messaging a forward-declared class

2011-04-10 Thread nicola at gcc dot gnu.org

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

   Summary: Missing warning when messaging a forward-declared
class
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org


The following testcase compiles with no warnings on GCC 4.7.0 20110326:

#include 

@class A;

@interface B
{
  id isa;
}
+ (void) doSomething;
@end

void test (void)
{
  [A doSomething];
}

While clang produces a hard error:

z.m:14:4: warning: receiver 'A' is a forward class and corresponding @interface
may not exist
  [A doSomething];
   ^
z.m:9:1: note: method 'doSomething' is used for the forward class
+ (void) doSomething;
^
1 warning generated.

In this case, the behaviour of clang seems better.  @class is really meant to 
resolve recursive declarations; it should always be followed by the 
corresponding @interface, particularly if you are going to message the class or 
objects of the class.

I would say that GCC should produce at least a warning in this case!

There's also the issue of whether the following testcase should also produce
a warning:

#include 

@class A;

@interface B
{
  id isa;
}
- (void) doSomething;
@end

void test (A *x)
{
  [x doSomething];
}

This is slightly different in that it is an instance message, as opposed to
a class message.  Neither GCC nor clang produce any warning or error here, but 
it sounds like a warning similar to the one above would be very appropriate.

Thanks

[Bug objc/48539] Missing warning when messaging a forward-declared class

2011-04-10 Thread nicola at gcc dot gnu.org

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.10 11:11:54
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-04-10 11:11:54 
UTC ---
Yes, it's confirmed with both 

gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)

and

gcc (GCC) 4.7.0 20110326 (experimental)

Thanks

[Bug lto/48538] GCC build fails with -flto in BOOT_CFLAGS

2011-04-10 Thread jafb at tinet dot org

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

--- Comment #2 from jafb at tinet dot org 2011-04-10 11:45:55 UTC ---
Ok. In the documentation it said that was equivalent to -flto in BOOT_CFLAGS,
that's why I used it.
Now I've checked bootstrap-lto.mk and looks like it disables lto when doing a
profiled bootstrap. Is it right? I wonder what gives better performance: lto or
profiled-driven optimizations...

[Bug debug/48540] New: [4.7 Regression] FAIL: 20_util/typeindex/comparison_operators.cc on powerpc-apple-darwin9

2011-04-10 Thread dominiq at lps dot ens.fr

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

   Summary: [4.7 Regression] FAIL:
20_util/typeindex/comparison_operators.cc on
powerpc-apple-darwin9
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9


At revision 172225 the test 20_util/typeindex/comparison_operators.cc fails on
with -m64 with

Executing on host: /opt/gcc/darwin_buildw/./gcc/g++ -shared-libgcc
-B/opt/gcc/darwin_buildw/./gcc -nostdinc++
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/src
-L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.7w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.7w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.7w/powerpc-apple-darwin9/include -isystem
/opt/gcc/gcc4.7w/powerpc-apple-darwin9/sys-include -m64
-B/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/src/.libs -g
-O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g
-O2 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/include/powerpc-apple-darwin9
-I/opt/gcc/darwin_buildw/powerpc-apple-darwin9/ppc64/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++
-I/opt/gcc/work/libstdc++-v3/include/backward
-I/opt/gcc/work/libstdc++-v3/testsuite/util
/opt/gcc/work/libstdc++-v3/testsuite/20_util/typeindex/comparison_operators.cc 
 -std=gnu++0x ./libtestc++.a /usr/lib/libiconv.dylib  -lm   -m64 -o
./comparison_operators.exe(timeout = 600)
/opt/gcc/work/libstdc++-v3/testsuite/20_util/typeindex/comparison_operators.cc:
In function 'void test01()':
/opt/gcc/work/libstdc++-v3/testsuite/20_util/typeindex/comparison_operators.cc:82:1:
internal compiler error: Bus error

The test was passing at revision 17193. It also pass if I remove the -g option
or change the optimization level to -O1. Unfortunately the test all passes
under gdb.

[Bug lto/48538] GCC build fails with -flto in BOOT_CFLAGS

2011-04-10 Thread rguenth at gcc dot gnu.org

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

--- Comment #3 from Richard Guenther  2011-04-10 
11:52:02 UTC ---
(In reply to comment #2)
> Ok. In the documentation it said that was equivalent to -flto in BOOT_CFLAGS,
> that's why I used it.
> Now I've checked bootstrap-lto.mk and looks like it disables lto when doing a
> profiled bootstrap. Is it right? I wonder what gives better performance: lto 
> or
> profiled-driven optimizations...

It disables LTO during the profile instrumented stage to speed up the
compile of that.  The final executables are still built with profile
feedback and LTO.

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

2011-04-10 Thread jb at gcc dot gnu.org

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

--- Comment #6 from Janne Blomqvist  2011-04-10 12:24:54 
UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Does any of the Fortran edit descriptors require, or for that matter 
> > > allow,
> > > this kind of "shortest decimal representation" output?
> > 
> > Well, the obvious(?) answer is the various descriptors with 0 width.
> 
> Not quite:
> 
> Since we're not talking about the shortest width (w) but the smallest number 
> of
> decimal digits in the fraction (d), only those descriptors where we can select
> "a processor-dependent reasonable value for d" can be "shortened":
> 
> That would be list-directed and G0 (but not G0.d).

What I meant was edit descriptors with w=0 and where d is not present. Sorry if
that wasn't clear.

> For all others the algorithm is still useful if we append zeros to fill the
> required width: it is better to print 0.300 than 0.296

I don't this is useful, actually. If the user explicitly asks for d decimal
digits, we should use the existing simple algorithm ("simple" compared to the
shortest-width one) to round to d digits, rather than finding the shortest
representation and pad with zeros if necessary.

> I'm still not sure where the Fortran standard says "a processor-dependent
> reasonable value for d"

I don't think you'll find that anywhere. If d is present, d digits must be
printed, assuming it fits in the field width. 

> that includes a "processor-dependent reasonable value
> for d which also depends on the internal value to be printed" because that
> would mess up tabular aligment for printing. This might be a feature users 
> rely
> on.

I think the intention with the w=0 edit descriptors is exactly that, the
compiler can choose the minimum width depending on the value (this being the
case where the shortest-width algorithm can be useful). If the user doesn't
want that, he can choose a non-zero width.

[Bug tree-optimization/48189] [4.3/4.4/4.5/4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0

2011-04-10 Thread steven at gcc dot gnu.org

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #3 from Steven Bosscher  2011-04-10 
13:33:30 UTC ---
I'd say probability is zero i.e. never executed, as a special case. Or if you
consider the edge always taken, then the probability should be
REG_BR_PROB_BASE. 

But zero seems more consistent:

Index: predict.c
===
--- predict.c   (revision 172225)
+++ predict.c   (working copy)
@@ -988,7 +988,14 @@
  else
continue;

- probability = ((REG_BR_PROB_BASE + nitercst / 2) / nitercst);
+ if (nitercst == 0 && predictor == PRED_LOOP_ITERATIONS)
+   /* If the prediction for number of iterations is zero, the exits
+  will never be taken.  Only make this prediction if we are quite
+  sure that the loop will never roll, from analysis.  */
+   probability = 0;
+ else
+   probability = ((REG_BR_PROB_BASE + nitercst / 2) / nitercst);
+
  predict_edge (ex, predictor, probability);
}
   VEC_free (edge, heap, exits);


Or maybe just not predict at all:

Index: predict.c
===
--- predict.c   (revision 172225)
+++ predict.c   (working copy)
@@ -988,6 +988,11 @@
  else
continue;

+ /* If the prediction for number of iterations is zero, do not
+predict the exit edges.  */
+ if (nitercst == 0)
+   continue;
+
  probability = ((REG_BR_PROB_BASE + nitercst / 2) / nitercst);
  predict_edge (ex, predictor, probability);
}

[Bug libstdc++/48541] New: std::function(std::_Function_base) should use std::addressof

2011-04-10 Thread n.fujita12 at gmail dot com

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

   Summary: std::function(std::_Function_base) should use
std::addressof
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n.fujit...@gmail.com


In std::_Function_base::_M_get_pointer, operator & is used to get a pointer of
the functor.
So, some callable objects which override operator & and they don't return their
pointer couldn't be held by std::function.


struct X {
  void operator ()() const {
std::cerr << "X()\n";
  }
  float operator &() const {
return 1.2345;
  }
};
int main() {
  X x;
  std::function f(x);
  return 0;
}

[Bug libstdc++/48541] std::function(std::_Function_base) should use std::addressof

2011-04-10 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.10 13:58:50
 Ever Confirmed|0   |1

[Bug bootstrap/48492] [4.7 Regression] LTO bootstrap failure in copy_constant

2011-04-10 Thread ebotcazou at gcc dot gnu.org

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.04.10 15:58:58
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2011-04-10 
15:58:58 UTC ---
Same error on sem_prag.adb linking gnat1.

[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)

2011-04-10 Thread redi at gcc dot gnu.org

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

--- Comment #12 from Jonathan Wakely  2011-04-10 
16:19:46 UTC ---
Author: redi
Date: Sun Apr 10 16:19:41 2011
New Revision: 172240

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172240
Log:
2011-04-10  Jonathan Wakely  

PR libstdc++/48465
* configure.ac (libtool_VERSION): Bump library version to 6:16:0.
* configure: Regenerate.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.16): Export missing symbols.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.16.


Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/config/abi/pre/gnu.ver
branches/gcc-4_6-branch/libstdc++-v3/configure
branches/gcc-4_6-branch/libstdc++-v3/configure.ac
branches/gcc-4_6-branch/libstdc++-v3/testsuite/util/testsuite_abi.cc

[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)

2011-04-10 Thread redi at gcc dot gnu.org

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

--- Comment #13 from Jonathan Wakely  2011-04-10 
16:20:50 UTC ---
Author: redi
Date: Sun Apr 10 16:20:42 2011
New Revision: 172241

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172241
Log:
2011-04-10  Jonathan Wakely  

PR libstdc++/48465
* configure.ac (libtool_VERSION): Bump library version to 6:16:0.
* configure: Regenerate.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.16): Export missing symbols.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.16.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc

[Bug libstdc++/48465] [4.6/4.7 Regression] undefined reference to std::basic_string::_S_compare(unsigned long, unsigned long)

2011-04-10 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.6.1, 4.7.0
 Resolution||FIXED
  Known to fail|4.6.1, 4.7.0|4.6.0

--- Comment #14 from Jonathan Wakely  2011-04-10 
16:21:48 UTC ---
fixed for 4.6.1

[Bug libstdc++/48541] std::function(std::_Function_base) should use std::addressof

2011-04-10 Thread redi at gcc dot gnu.org

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

--- Comment #1 from Jonathan Wakely  2011-04-10 
16:29:09 UTC ---
Author: redi
Date: Sun Apr 10 16:29:05 2011
New Revision: 172242

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172242
Log:
2011-04-10  Jonathan Wakely  

PR libstdc++/48541
* include/std/functional (_Base_manager::_M_get_pointer): Use
addressof.
* testsuite/20_util/function/48541.cc: New.


Added:
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/function/48451.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/std/functional

[Bug libstdc++/48541] std::function(std::_Function_base) should use std::addressof

2011-04-10 Thread redi at gcc dot gnu.org

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

--- Comment #2 from Jonathan Wakely  2011-04-10 
16:36:01 UTC ---
Author: redi
Date: Sun Apr 10 16:35:58 2011
New Revision: 172244

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172244
Log:
2011-04-10  Jonathan Wakely  

PR libstdc++/48541
* include/std/functional (_Base_manager::_M_get_pointer): Use
addressof.
* testsuite/20_util/function/48541.cc: New.


Added:
trunk/libstdc++-v3/testsuite/20_util/function/48541.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/functional

[Bug libstdc++/48541] std::function(std::_Function_base) should use std::addressof

2011-04-10 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.1

--- Comment #3 from Jonathan Wakely  2011-04-10 
16:36:57 UTC ---
fixed for 4.6.1 - thanks for the report

[Bug fortran/47713] String comparison optimization with LLE and friends

2011-04-10 Thread tkoenig at gcc dot gnu.org

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #1 from Thomas Koenig  2011-04-10 
17:13:04 UTC ---
Fixed with http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00146.html
(which didn't reference this PR).

Closing.

[Bug fortran/25708] Module loading is not good at all

2011-04-10 Thread jvdelisle at gcc dot gnu.org

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

Jerry DeLisle  changed:

   What|Removed |Added

 AssignedTo|pault at gcc dot gnu.org|jvdelisle at gcc dot
   ||gnu.org

--- Comment #16 from Jerry DeLisle  2011-04-10 
17:47:07 UTC ---
Paul, taking this one if you do not mind.

I have run some tests.  I replaced the long strings in the various minit
invocations with a 2 or 3 character mnemonic. For a particularly large module
the size of the .mod file created is:

un-patched -> 8210691 bytes

gzipped -> 724854 bytes

patched ->6280606 bytes

patched and zipped ->  714777 bytes

Compressing the file is quite good.  There is no particular advantage to
changing the minit strings if one is going to compress the file.  The question
is then what cost in time do we have of actually compressing and decompressing.

The above just deals with raw file size and I think compression is a good idea.
 If we leave the strings alone, we could allow manual decompressing the files
to look at them for debugging purposes.

The next thing I would like to consider is some sort of module caching. Let's
say we create a module namespace for each module file.  I would suggest
allowing a fixed number of these to conserve memory usage.  Modules that are
USEed repeatedly would be retained, free up ones not used if more are needed. 
I am thinking of some sort of leased recently used scheme.

Another thing I wonder about is how efficiently do we retrieve from this name
space. (I have more to study on the internals of module.c)

[Bug fortran/48543] New: Collapse identical strings

2011-04-10 Thread tkoenig at gcc dot gnu.org

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

   Summary: Collapse identical strings
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org


The two programs yield identical results. The second program
results in a shorter object file because the 

ig25@linux-fd1f:~/Krempel/String> cat foo.f90
program main
  character(len=17) :: a
  character(len=34) :: b
  a = 'Supercalifragilis'
  b = 'Supercalifragilisticexpialidocious'
  print *,a," ",b
end program main
ig25@linux-fd1f:~/Krempel/String> cat bar.f90
program main
  character(len=17) :: a
  character(len=34) :: b
  a = 'Supercalifragilisticexpialidocious'
  b = 'Supercalifragilisticexpialidocious'
  print *,a," ",b
end program main
ig25@linux-fd1f:~/Krempel/String> gfortran -c -Os foo.f90
ig25@linux-fd1f:~/Krempel/String> gfortran -c -Os bar.f90
ig25@linux-fd1f:~/Krempel/String> ls -l foo.f90 bar.f90
-rw-r--r-- 1 ig25 users 184 10. Apr 19:02 bar.f90
-rw-r--r-- 1 ig25 users 167 10. Apr 19:01 foo.f90
g25@linux-fd1f:~/Krempel/String> strings foo.o | grep Super
SupercalifragilisSupercalifragilisticexpialidocious
ig25@linux-fd1f:~/Krempel/String> strings bar.o | grep Super
Supercalifragilisticexpialidocious

This is an optimization that could be done for -Os, at least.

[Bug target/47908] attribute((optimize(2))) causes ICE in m68k_sched_issue_rate

2011-04-10 Thread alanh at fairlite dot co.uk

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

Alan Hourihane  changed:

   What|Removed |Added

 CC||alanh at fairlite dot co.uk

--- Comment #3 from Alan Hourihane  2011-04-10 
18:36:37 UTC ---
I'm also hitting this when compiling tar 1.26 with gcc 4.5.2 from Gentoo.

[Bug fortran/48462] [4.6/4.7 Regression] realloc on assignment: matmul Segmentation Fault with Allocatable Array

2011-04-10 Thread pault at gcc dot gnu.org

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

--- Comment #5 from Paul Thomas  2011-04-10 18:48:40 
UTC ---
(In reply to comment #4)
> This should be easy. The only difference between default (failing) and

snip

> which sort of does a job on 'a'.  I say that it is easy because there are not
> many sections in trans-xxx that hide behind the -frealloc-lhs condition.

The problem is with trans-expr.c (realloc_lhs_bounds_for_intrinsic_call), where
the result data is freed, in order to signal to the library that an allocation
is needed.

The easiest solution would be to use arrayfunc_assign_needs_temporary to force
temporary creation, if the function is intrinsic and the lhs variable appears
anywhere in the rhs.  I'll put thinking hat on to see if something more elegant
comes to mind.

Paul

[Bug c/48544] New: "might be clobbered by ‘longjmp’" diagnostic for unmodified variable

2011-04-10 Thread adl at gnu dot org

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

   Summary: "might be clobbered by ‘longjmp’" diagnostic for
unmodified variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gnu.org


Created attachment 23939
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23939
preprocessed input

% uname -a
Linux hush 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux
% gcc-4.6 --version
gcc-4.6 (Debian 4.6.0-2) 4.6.1 20110329 (prerelease)
Copyright (C) 2011 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.
% cat foo.c
#include 

jmp_buf env;
void foo(int);

int bar(int r, int var)
{
  if (var)
return r;
  if (setjmp(env) == 0)
foo(r);
  return 0;
}
% gcc-4.6 -Wall -Wextra -O2 -c foo.c
foo.c: In function ‘bar’:
foo.c:6:13: warning: argument ‘r’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Wclobbered]

If I understand this message correctly, GCC is warning me that "r" might be
reset to the value it had before calling setjmp().  However, I never changed
the value of "r", so I don't think this warning should be emitted.

Note that removing the "if (var) return r;" lines makes the warning go away.

[Bug c/48545] New: dereferencing does not work as expected

2011-04-10 Thread gerald at itzgrund dot net

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

   Summary: dereferencing does not work as expected
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ger...@itzgrund.net


Created attachment 23940
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23940
minimum example of the problem

Dear gcc team,

I think I've found a bug on dereferncing pointers. An example is attached. The
problem exists inside the function outputfunc where the parameter output will
not be dereferenced as expected. You only have to compile the example and take
look at the output. There is a workaround that is also included inside the
example code of outputfunc (variable validoutput).

I hope that I did not overlook something inside the C-Standard but I think the
parameter output should be dereferenced just like the way it is done for
validoutput.

Best regards,
Gerald

[Bug c/48545] dereferencing does not work as expected

2011-04-10 Thread d.g.gorbachev at gmail dot com

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

--- Comment #1 from Dmitry Gorbachev  
2011-04-10 23:44:58 UTC ---
Hi!

I'm not a GCC team, but I believe that GCC is correct here.

An argument called "output" has a type "pointer to an array of 132 unsigned
chars". "*output" has a type "array of 132 unsigned chars", which is implicitly
converted to "pointer to an unsigned char", according to C language rules.
Whereas the actual argument, "&mytest", has a different type "pointer to a
pointer to an unsigned char".

[Bug c/48546] New: lto-wrapper returned 1 exit

2011-04-10 Thread rootkit85 at yahoo dot it

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

   Summary: lto-wrapper returned 1 exit
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rootki...@yahoo.it


I tried to compile a kernel module with LTO but the compiler died when linking:

gcc -flto -nostdlib -nodefaultlibs -r -Wl,-m -Wl,elf_x86_64
-Wl,-T/usr/src/linux-2.6.38/scripts/module-common.lds -Wl,--build-id  -o
/home/matteo/Downloads/compat-wireless-2011-03-31/drivers/net/wireless/ath/ath9k/ath9k.i
/home/matteo/Downloads/compat-wireless-2011-03-31/drivers/net/wireless/ath/ath9k/ath9k.o
/home/matteo/Downloads/compat-wireless-2011-03-31/drivers/net/wireless/ath/ath9k/ath9k.mod.o
lto1: internal compiler error: Errore di segmentazione
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

[Bug libstdc++/48547] New: iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

   Summary: iostream and some other C++ libraries do not work with
-fpack-struct
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jmich...@yahoo.com


Created attachment 23941
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23941
output text from the compiler

iostream and some other C++ libraries do not work with -fpack-struct

this is in 4.5.2, 4.5.3, and 4.7.0.  it's been a problem for quite a long time.

commercial compilers such as Microsoft Visual C++ and Borland do not have a
problem with the equivalent compiler switch.

It would take me a long time to generate a complete list of libraries which
work with this switch and those which don't.

C:\prj\test\mingw-w64\pack-struct>c:\mingw-w32-bin_i686-mingw_20110402\bin\i686-w64-mingw32-g++.exe
-Wall -W -v -save-temps -O   -s -fstack-check -fpack-struct
-static-libgcc  -isystem /libpq/ -isystem /libpq/server/libpq/ -isystem
/prj/fltk/fltk-1.1.10/ -isystem /prj/fltk/fltk-1.1.10/lib/ -isystem
/prj/zlib-1.2.5/ -st
d=c++0x -o pack-struct.exe pack-struct.cpp
-lgcc -lstdc++  2>errgw

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #1 from Jim Michaels  2011-04-11 
04:04:50 UTC ---
Created attachment 23942
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23942
pack-struct.ii

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #2 from Jim Michaels  2011-04-11 
04:06:00 UTC ---
Created attachment 23943
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23943
pack-struct.cpp

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #3 from Jim Michaels  2011-04-11 
04:06:35 UTC ---
I attached the test code.

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #4 from Jim Michaels  2011-04-11 
04:27:38 UTC ---
by the way, in dealing with packed structures in code, I don't know how it is
normally handled in compilers and system libraries such as Win32, Mac OS X, and
Linux because I haven't taken time time to look at the code, but it were me, I
would just turn on the -pack-struct switch and let the compiler do it all.

I have a number of programs that use structures, and I don't know of
compiler-specific ways of doing structure packing using pragmas or whatever.  I
am learning though.

but I think this is an important compiler switch which should not be ignored. 
after all, it's there, and it's for making sure sructures get packed.  My
thinking was, if the libraries are not written in a way so that they handle
being packed, then something needs to be fixed so that they can.

I had at least 1 or 2 important programs out of 26 I could not write or had to
completely rewrite because of packing problems in gcc.

I think if you include iterator, vector, and string in a separate file with
-pack-struct, it causes the same error, because somehow it includes iostream.
catch-22 if you want to get any real work done!
this example is pack-struct2.*

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #5 from Jim Michaels  2011-04-11 
04:29:20 UTC ---
Created attachment 23944
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23944
output from the compiler, pack-struct2

this is vector, iterator, and string

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #6 from Jim Michaels  2011-04-11 
04:30:26 UTC ---
Created attachment 23945
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23945
pack-struct2.cpp

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #7 from Jim Michaels  2011-04-11 
04:31:13 UTC ---
Created attachment 23946
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23946
pack-struct2.ii

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #8 from Jim Michaels  2011-04-11 
04:48:41 UTC ---
oops. bug in code.  let me recode to show problem.

[Bug lto/48548] New: recent svn version gcc (4.6? 4.7?) compile failed

2011-04-10 Thread kuh3h3 at gmail dot com

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

   Summary: recent svn version gcc (4.6? 4.7?) compile failed
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kuh...@gmail.com


i tried to compile recent svn version gcc with cloog(icl) or cloog(ppl-legacy).
but failed . error message are same in two builds.


../.././gcc -I../.././gcc/. -I../.././gcc/../include
-I../.././gcc/../libcpp/include -I/media/sdc2/gcc-4.5.1/include
-I/media/sdc2/gcc-4.5.1/include -I/media/sdc2/gcc-4.5.1/include 
-I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid
-I../libdecnumber -I/media/sdc2/gcc-4.5.1/include 
-I/media/sdc2/gcc-4.5.1/include -DCLOOG_INT_GMP -DCLOOG_ORG 
../.././gcc/graphite.c -o graphite.o
In file included from ../.././gcc/graphite-cloog-util.h:25:0,
 from ../.././gcc/graphite-clast-to-gimple.h:24,
 from ../.././gcc/graphite.c:54:
../.././gcc/graphite-cloog-compat.h:86:1: error: redefinition of
‘cloog_statement_usr’
/media/sdc2/gcc-4.5.1/include/cloog/statement.h:66:21: note: previous
definition of ‘cloog_statement_usr’ was here
../.././gcc/graphite-cloog-compat.h: In function ‘cloog_statement_usr’:
../.././gcc/graphite-cloog-compat.h:88:12: error: ‘CloogStatement’ has no
member named ‘usr’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:91:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’
or ‘__attribute__’ before ‘*’ token
../.././gcc/graphite-cloog-compat.h:98:43: error: expected ‘)’ before ‘*’ token
../.././gcc/graphite-cloog-compat.h:103:35: error: expected ‘=’, ‘,’, ‘;’,
‘asm’ or ‘__attribute__’ before ‘*’ token
../.././gcc/graphite-cloog-compat.h:110:48: error: expected ‘)’ before ‘*’
token
../.././gcc/graphite-cloog-compat.h:116:1: error: redefinition of
‘cloog_program_nb_scattdims’
/media/sdc2/gcc-4.5.1/include/cloog/program.h:86:19: note: previous definition
of ‘cloog_program_nb_scattdims’ was here
../.././gcc/graphite-cloog-compat.h: In function ‘cloog_program_nb_scattdims’:
../.././gcc/graphite-cloog-compat.h:118:14: error: ‘CloogProgram’ has no member
named ‘nb_scattdims’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:122:1: error: redefinition of
‘cloog_program_set_nb_scattdims’
/media/sdc2/gcc-4.5.1/include/cloog/program.h:91:20: note: previous definition
of ‘cloog_program_set_nb_scattdims’ was here
../.././gcc/graphite-cloog-compat.h: In function
‘cloog_program_set_nb_scattdims’:
../.././gcc/graphite-cloog-compat.h:124:7: error: ‘CloogProgram’ has no member
named ‘nb_scattdims’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:128:1: error: redefinition of
‘cloog_program_names’
/media/sdc2/gcc-4.5.1/include/cloog/program.h:116:27: note: previous definition
of ‘cloog_program_names’ was here
../.././gcc/graphite-cloog-compat.h: In function ‘cloog_program_names’:
../.././gcc/graphite-cloog-compat.h:130:14: error: ‘CloogProgram’ has no member
named ‘names’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:134:1: error: redefinition of
‘cloog_program_set_names’
/media/sdc2/gcc-4.5.1/include/cloog/program.h:121:20: note: previous definition
of ‘cloog_program_set_names’ was here
../.././gcc/graphite-cloog-compat.h: In function ‘cloog_program_set_names’:
../.././gcc/graphite-cloog-compat.h:136:7: error: ‘CloogProgram’ has no member
named ‘names’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:140:1: error: redefinition of
‘cloog_program_set_context’
/media/sdc2/gcc-4.5.1/include/cloog/program.h:101:20: note: previous definition
of ‘cloog_program_set_context’ was here
../.././gcc/graphite-cloog-compat.h: In function ‘cloog_program_set_context’:
../.././gcc/graphite-cloog-compat.h:142:7: error: ‘CloogProgram’ has no member
named ‘context’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:146:1: error: redefinition of
‘cloog_program_set_loop’
/media/sdc2/gcc-4.5.1/include/cloog/program.h:111:20: note: previous definition
of ‘cloog_program_set_loop’ was here
../.././gcc/graphite-cloog-compat.h: In function ‘cloog_program_set_loop’:
../.././gcc/graphite-cloog-compat.h:148:7: error: ‘CloogProgram’ has no member
named ‘loop’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:152:1: error: redefinition of
‘cloog_program_blocklist’
/media/sdc2/gcc-4.5.1/include/cloog/program.h:126:31: note: previous definition
of ‘cloog_program_blocklist’ was here
../.././gcc/graphite-cloog-compat.h: In function ‘cloog_program_blocklist’:
../.././gcc/graphite-cloog-compat.h:154:14: error: ‘CloogProgram’ has no member
named ‘blocklist’
../.././gcc/graphite-cloog-compat.h: At top level:
../.././gcc/graphite-cloog-compat.h:158:1: error: redefinition of
‘cloog_pr

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

Jim Michaels  changed:

   What|Removed |Added

  Attachment #23941|0   |1
is obsolete||
  Attachment #23942|0   |1
is obsolete||
  Attachment #23943|0   |1
is obsolete||
  Attachment #23944|0   |1
is obsolete||
  Attachment #23945|0   |1
is obsolete||
  Attachment #23946|0   |1
is obsolete||

--- Comment #9 from Jim Michaels  2011-04-11 
05:01:25 UTC ---
Created attachment 23947
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23947
pack-struct.cpp

the iostream bug

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #10 from Jim Michaels  2011-04-11 
05:02:18 UTC ---
Created attachment 23948
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23948
pack-struct2.cpp

the iterator bug

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #11 from Jim Michaels  2011-04-11 
05:03:01 UTC ---
Created attachment 23949
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23949
pack-struct2.ii

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #12 from Jim Michaels  2011-04-11 
05:03:53 UTC ---
Created attachment 23950
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23950
pack-struct.ii

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #13 from Jim Michaels  2011-04-11 
05:04:56 UTC ---
Created attachment 23951
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23951
compiler output, pack-struct

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #14 from Jim Michaels  2011-04-11 
05:05:33 UTC ---
Created attachment 23952
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23952
compiler output, pack-struct2

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread jmichae3 at yahoo dot com

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

--- Comment #15 from Jim Michaels  2011-04-11 
05:06:05 UTC ---
there. fixed the test cases.

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread d.g.gorbachev at gmail dot com

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

--- Comment #16 from Dmitry Gorbachev  
2011-04-11 05:46:07 UTC ---
> I don't know of compiler-specific ways of doing structure
> packing using pragmas or whatever.  I am learning though.

Use GCC __attribute__((packed)) or #pragma pack (which is also supported by
MSVC). They are described in the GCC documentation.

[Bug tree-optimization/48497] gfortran.dg/graphite/vect-pr40979.f90 FAILs without -march=pentium4

2011-04-10 Thread allan at archlinux dot org

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

--- Comment #1 from Allan McRae  2011-04-11 
06:12:28 UTC ---
I see the same failure with -march=i686 on i686-pc-linux-gnu with gcc-4.6.0. 
Using -march=pentium4 makes this pass.

[Bug libstdc++/48547] iostream and some other C++ libraries do not work with -fpack-struct

2011-04-10 Thread pinskia at gcc dot gnu.org

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #17 from Andrew Pinski  2011-04-11 
06:26:43 UTC ---
-fpack-struct changes the ABI so you really can't use this option unless you
compile everything with it.

[Bug rtl-optimization/48549] New: [4.6/4.7 Regression] Combiner ICE with -g

2011-04-10 Thread jakub at gcc dot gnu.org

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

   Summary: [4.6/4.7 Regression] Combiner ICE with -g
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


void
foo (void *from, void *to)
{
  long offset = reinterpret_cast (to) - reinterpret_cast (from);
  if (offset != static_cast (offset))
*(int *) 0xC0DE = 0;
  reinterpret_cast (from)[1] = offset;
}
struct A
{
  A () : a () {}
  A (void *x) : a (x) {}
  void *bar () { return a; }
  void *a;
};
struct C;
struct D;
struct E : public A
{
  C m1 (int);
  D m2 ();
  E () {}
  E (A x) : A (x) {}
};
struct C : public E
{
  C () {}
  C (void *x) : E (x) {}
};
struct D : public E
{
  D (void *x) : E (x) {}
};
C
E::m1 (int x)
{
  return (reinterpret_cast (bar ()) + x);
}
D
E::m2 ()
{
  return reinterpret_cast (bar ());
}
struct B
{
  E a;
  unsigned b : 16;
  unsigned c : 1;
};
void
baz (B *x)
{
  for (unsigned i = 0; i < 64; i++)
{
  D d = x[i].a.m2 ();
  C c = x[i].a.m1 (x[i].c);
  foo (d.bar (), c.bar ());
}
}

ICEs with -g -O2 on x86_64-linux, starting with 172109/172110.

[Bug bootstrap/48520] "make install" for cross-compile silently clobbers target-gcc

2011-04-10 Thread tim.vanholder at anubex dot com

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

--- Comment #2 from tim.vanholder at anubex dot com 2011-04-11 06:56:27 UTC ---
Fair enough.

However, this was the _only_ (noticeable) breakage resulting from this
configuration.
If that's really all there is I don't see why this couldn't/shouldn't simply be
handled by the makefile rule.
Also, I don't really understand why it's ok for "make install" to silently
ignore errors during the creation of the (hard links to the) binaries in the
installation tree. That seems to be a rather fundamental aspect of "make
install".

If there are more (hidden) breakages resulting from this, maybe this
"program-prefix should not be '-'" rule should be enforced by configure
(as far as I can tell, it's not mentioned anywhere in the source tree).
In fact, gcc/configure currently includes

# The aliases save the names the user supplied, while $host etc.
# will get canonicalized.
test -n "$target_alias" &&
  test "$program_prefix$program_suffix$program_transform_name" = \
NONENONEs,x,x, &&
  program_prefix=${target_alias}-

so it even explictly sets the program prefix to the target_alias (if one is
given), meaning that even if I had not explicitly given
--program-prefix=mingw32-, configure would have set that up for me
automatically (provided I also left off the --program-suffix, which for a
cross-compiler would not be entirely needed either).
So I guess the only issue is when both prefix & suffix are set to the standard
ones used during installation, which should be handled perfectly well by
adjusting gcc/Makefile.am to only do the rm+ln if GCC_INSTALL_NAME does not
match the canon_target-gcc-version construct.

69 matches

Mail list logo