--- Comment #16 from eres at il dot ibm dot com 2007-11-17 06:36 ---
(In reply to comment #15)
> (In reply to comment #14)
> > I still can't reproduce it. What does your gcc -v say?
> Configured with: ../gcc/configure --prefix=/home/eres/check_final/build
> --with-cpu=default32 --enable
--- Comment #15 from eres at il dot ibm dot com 2007-11-17 06:24 ---
(In reply to comment #14)
> I still can't reproduce it. What does your gcc -v say?
Configured with: ../gcc/configure --prefix=/home/eres/check_final/build
--with-cpu=default32 --enable-checking --disable-bootstrap --e
--- Comment #7 from dirtyepic at gentoo dot org 2007-11-17 02:19 ---
Confirmed, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34113
--- Comment #2 from danglin at gcc dot gnu dot org 2007-11-17 02:03 ---
Actually, it's the following change:
2007-11-08 Tom Tromey <[EMAIL PROTECTED]>
* common.opt (fshow-column): Default to 0.
* configure: Rebuilt.
* configure.ac (--enable-mapped-location): D
tried the following code on both gcc 4.1 and gcc 3.2,:
int result, i;
i = 0;
result = -2*abs(i-2);
printf("result = %d\n", result);
the result is 4, while the
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-17 00:22
---
Fixed. Thanks for the bug report.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-17 00:10
---
Subject: Bug 34108
Author: fxcoudert
Date: Sat Nov 17 00:10:00 2007
New Revision: 130249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130249
Log:
PR fortran/34108
* io.c (check_format_s
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-17 00:07
---
While I'm trying to understand what happens, I should say that a simply
workaround is to make your calculation happen in double precision (change
"3.14159" into "3.14159d0"; after all, you want a double-precision
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-11-16 23:42
---
(In reply to comment #6)
> Yes. When -m2e is specified on SH, DOUBLE_TYPE_SIZE is set to
> 32 and double_type_node has the SF type.
> Perhaps all targets which set DOUBLE_TYPE_SIZE to other than 64
> might have t
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-11-16 23:29
---
I submitted a patch that removes the ICE and adds a better error message.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from listor3 dot rombobeorn at tdcpost dot se 2007-11-16
23:16 ---
I've never seen any numbers on just how expensive -gnato is, but provided that
the cost is moderate I think it should be on by default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-11-16
23:09 ---
> The problem with decorate is that its meaning depends on the platform. It may
> decorate the "name" of alias with a "_" prefix and "@n" postfix or only with a
> "_" prefix. Maybe one should start with
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33583
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:46
---
I hope it's now fixed. If there is something more to it, please reopen the PR
or file a new one.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:46
---
I hope it's now fixed. If there is something more to it, please reopen the PR
or file a new one.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:40
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-11-16 22:38 ---
backtrace is part of the GNU libc project and not the GCC Project, report the
bug to them (http://www.sourceware.org/bugzilla ).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:38
---
Subject: Bug 33957
Author: fxcoudert
Date: Fri Nov 16 22:38:21 2007
New Revision: 130246
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130246
Log:
PR fortran/33957
* gfortran.dg/initiali
--- Comment #4 from wilson at gcc dot gnu dot org 2007-11-16 22:37 ---
This problem occurs if you accidentally run
../gcc/gcc/configure
instead of
../gcc/configure
I've tried looking at make -d output, and there isn't enough info there to see
what is going wrong. In the second case
--- Comment #2 from stephenc at cisco dot com 2007-11-16 22:36 ---
Created an attachment (id=14570)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14570&action=view)
Preprocessed example source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34129
--- Comment #1 from stephenc at cisco dot com 2007-11-16 22:35 ---
Created an attachment (id=14569)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14569&action=view)
Output from gcc -v -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34129
The following stack shows backtrace () requiring malloc () when initializing.
This makes writing memory tools slightly problematic. In the example, the code
deadlocks in my malloc () during initialization:
#0 malloc (size=28) at example.cpp:17
#1 0x006821d8 in _dl_map_object_deps () from /lib/ld
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:31
---
Subject: Bug 33583
Author: fxcoudert
Date: Fri Nov 16 22:31:28 2007
New Revision: 130245
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130245
Log:
PR libfortran/33583
PR libfortran/33698
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:31
---
Subject: Bug 33698
Author: fxcoudert
Date: Fri Nov 16 22:31:28 2007
New Revision: 130245
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130245
Log:
PR libfortran/33583
PR libfortran/33698
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:24
---
Reopening, since the fix cause a regression (PR 34084). Please remember to fix
both problems at the same time. The other problem is:
INCLUDE 'anything'
PROGRAM test_cg
END PROGRAM test_cg
The INCLUDE file can c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:24
---
Regression fixed by reverting the patch, sorry for the breakage.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
The following codes (compiled as demo1.f and demo2.f)
PROGRAM demo1 PROGRAM demo2
integer i integer i
double precision result double precision result
do i=1,800do i=1,5
result =
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:20
---
Subject: Bug 33739
Author: fxcoudert
Date: Fri Nov 16 22:20:44 2007
New Revision: 130244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130244
Log:
PR fortran/33739
PR fortran/34084
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-11-16 22:20
---
Subject: Bug 34084
Author: fxcoudert
Date: Fri Nov 16 22:20:44 2007
New Revision: 130244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130244
Log:
PR fortran/33739
PR fortran/34084
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-16 22:12 ---
There is no need for this any more. It is not that useful really anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from pinskia at gmail dot com 2007-11-16 22:11 ---
Subject: Re: too agressive printf optimization
> Is there any difference in the standard behaviour between printf("%s", NULL)
> and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
> but neither
> Is there any difference in the standard behaviour between printf("%s", NULL)
> and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
> but neither puts(NULL) nor fprintf(stdout, "%s", NULL) do?
No both are undefined.
-- Pinski
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-11-16 21:51
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-16 21:50
---
Subject: Bug 34030
Author: rguenth
Date: Fri Nov 16 21:50:20 2007
New Revision: 130242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130242
Log:
2007-11-16 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-16 21:45 ---
Subject: Bug 34030
Author: rguenth
Date: Fri Nov 16 21:44:58 2007
New Revision: 130240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130240
Log:
2007-11-16 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-16 21:35 ---
Subject: Bug 34030
Author: rguenth
Date: Fri Nov 16 21:34:39 2007
New Revision: 130238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130238
Log:
2007-11-16 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #4 from pluto at agmk dot net 2007-11-16 21:34 ---
--enable-concept-checks in current boost-based way won't be fixed.
we're waiting for real concepts from c++0x.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2007-11-16 21:22 ---
Ah! ubound.51 is not declared anywhere in spec_test.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
--- Comment #9 from ian at davenant dot greenend dot org dot uk 2007-11-16
21:18 ---
All that's really needed is to remember all of the unknown -Wno-* options seen.
From the point of view of the core of the option parser, accept them, but just
store the string as provided. When the fi
--- Comment #14 from steven at gcc dot gnu dot org 2007-11-16 21:15 ---
I still can't reproduce it. What does your gcc -v say?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #1 from rwgk at yahoo dot com 2007-11-16 21:11 ---
Created an attachment (id=14568)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14568&action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34127
/vol1/tmp/rwgk/gcc_trunk_130232_x86_64_fc7
--enable-languages=c,c++,fortran --with-mpfr=/usr
Thread model: posix
gcc version 4.3.0 20071116 (experimental) (GCC)
I'll attach a stand-alone reproducer.
It works with -O0 but not -O1 or higher:
% gcc -c -fno-strict-aliasing -O1 -Wall ice_ssa.c
ice_
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-11-16 21:00 ---
Hi Mark,
this should probably be a P1. Booting on Linux isn't all that
uncommon.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from terry at chem dot gu dot se 2007-11-16 20:57 ---
I'd just like to remind everyone that this is still an issue in gcc version
4.3.0 20071109
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-11-16 20:56 ---
Created an attachment (id=14567)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14567&action=view)
gcc/Makefile
Makefile in gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34126
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-11-16 20:55 ---
Created an attachment (id=14566)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14566&action=view)
Output of "make bootstrap"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34126
bootstrap fails with i686-pc-linux-gnu with
revision 130208.
Configured with
$ ../../gcc/trunk/configure --prefix=$HOME --enable-languages=c,fortran
make bootstrap then fails with
Error message:
build/genmodes -h > tmp-modes.h
/bin/sh: build/genmodes: No such file or directory
make[3]: *** [s-
--- Comment #6 from laurent at ient dot rwth-aachen dot de 2007-11-16
20:42 ---
> Note that for completely inlining kernels you can use the
> __attribute__((flatten))
> on the *calling* function. Usually with expression templates that is the
> function
> containing the loops, like
> vo
--- Comment #6 from pault at gcc dot gnu dot org 2007-11-16 20:34 ---
The reduced testcase of #2 is fixed by:
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 129882)
--- gcc/fortran/resolve.c
--- Comment #16 from jakub at gcc dot gnu dot org 2007-11-16 20:29 ---
Tried to bootstrap that, and while just for make check it basically just
needed gcc_assert (!value || !TREE_SIDE_EFFECTS (value));
because e.g. some Fortran testcases have value == NULL,
bootstrap fails, e.g. on i386.
--- Comment #1 from pcarlini at suse dot de 2007-11-16 20:26 ---
*** This bug has been marked as a duplicate of 34124 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pinskia at gmail dot com 2007-11-16 20:26 ---
Subject: Re: Please enable stack checking (-fstack-check) by default
On 16 Nov 2007 18:35:15 -, ebotcazou at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> That's not true of probes in general, only of the generic
--- Comment #1 from pcarlini at suse dot de 2007-11-16 20:26 ---
*** Bug 34125 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34124
On 16 Nov 2007 18:35:15 -, ebotcazou at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> That's not true of probes in general, only of the generic implementation of
> the probing method in GCC. The implementation on Alpha/Tru64 doesn't suffer
> from this defect for example.
Or even the spu-el
Hi,
Running the following code:
#include
using namespace std;
class CBase {};
class CDerived : public CBase {};
void Set(auto_ptr base)
{
}
int main(int argc, char *argv[])
{
auto_ptr derived(new CDerived);
Set(derived); // error: conversion from 'std::auto_ptr' to
'std::auto_ptr' is am
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-16 13:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-16 14:50 ---
/usr/src/gcc/obj35/gcc/xgcc -B /usr/src/gcc/obj35/gcc/ -v 2>&1 | tail -n 1;
/usr/src/gcc/obj35/gcc/xgcc -B /usr/src/gcc/obj35/gcc/ -m32 -O2 -ffloat-store
-o pr33088{,.c} -lm; ./pr33088; echo $?
gcc version 4.3.0 200711
--- Comment #6 from pault at gcc dot gnu dot org 2007-11-16 14:49 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-11-16 20:10 ---
I'm working on it
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #8 from manu at gcc dot gnu dot org 2007-11-16 20:01 ---
> Specification of the proposed new behaviour:
>
> 1. GCC should ignore unknown -Wno-* options if no other warnings are to
>be issued. This is always correct since the only effect of such an
>option would be t
--- Comment #6 from rob dot quill at gmail dot com 2007-11-16 20:00 ---
I'm working on adding a new pass for this.
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33092
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-16 19:57 ---
*** Bug 34116 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-16 19:57 ---
This is not a GCC bug. There are no computed gotos in your function so the
label can be moved anywhere around. The scheduler moves around the label in
this case.
*** This bug has been marked as a duplicate of 28581
Hi,
Running the following code:
#include
using namespace std;
class CBase {};
class CDerived : public CBase {};
void Set(auto_ptr base)
{
}
int main(int argc, char *argv[])
{
auto_ptr derived(new CDerived);
Set(derived); // error: conversion from 'std::auto_ptr' to
'std::auto_ptr' is am
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-16 15:49 ---
What does -Winline say?
Have you tried with always_inline? Example:
/* Prototype. */
inline void foo (const char) __attribute__((always_inline));
See
http://gcc.gnu.org/onlinedocs/gcc/Function-Attribut
--- Comment #2 from sam at rfc1149 dot net 2007-11-16 14:14 ---
This bug does not exist in current GCC sources, which have a special test case
for 255.255.255.255 in g-socket.adb. I suggest that this bug be closed.
--
sam at rfc1149 dot net changed:
What|Removed
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-11-16 18:35
---
> GCC supports two ways to implement stack overflow checks: using guard pages
> called "probes", and inserting stack checking code into every subprogram.
That's confused. Probes are not "guard pages" and you alw
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-16 19:32 ---
(In reply to comment #1)
> aligned can never decrease the required alignment.
>
Can we detect this and emit a diagnostic? We do it for declarations already but
not for types. I tried the following patch as a wild gues
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-16 18:20 ---
Or rather a frontend bug if it doesn't promote either the integer to a pointer
or the pointer to an integer:
./cc1 -quiet -O2 t.i -quiet
t.i: In function foo:
t.i:9: warning: comparison between pointer and integer
--- Comment #1 from niklas dot holsti at tidorum dot fi 2007-11-16 18:19
---
It would certainly be in the Ada spirit to have stack-checking enabled by
default.
If GCC offers a selection of stack-checking methods, I think the default method
should be the most reliable and general one, e
--- Comment #14 from tbm at gcc dot gnu dot org 2007-11-16 19:16 ---
*** Bug 31080 has been marked as a duplicate of this bug. ***
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from tbm at gcc dot gnu dot org 2007-11-16 19:16 ---
Works for me with trunk.
*** This bug has been marked as a duplicate of 31037 ***
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-11-16 18:48 ---
Created an attachment (id=14565)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14565&action=view)
patch
Still needs testing, applies to all branches and trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #2 from tbm at cyrius dot com 2007-11-16 19:14 ---
This was introduced between 20070422 and 20070515.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34123
--- Comment #1 from tbm at cyrius dot com 2007-11-16 19:08 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
static unsigned char sbox[] = {
};
void MD2Transform (unsigned char state[16])
{
unsigned char t = 0;
int i, j;
for (i = 0; i < 16; i++)
{
for (j = 0; j
With current trunk:
(sid)[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O -ftree-loop-linear
md2.c
md2.c: In function 'MD2Transform':
md2.c:6: error: definition in block 11 does not dominate use in block 7
for SSA_NAME: t_20 in statement:
t_10 = PHI
PHI argument
t_20
for PHI node
t_10 = P
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-11-16 18:38 ---
On the trunk this doesn't fail because there STRIP_SIGN_NOPS (as applied to
comparisons) doesn't strip conversions to/from pointers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34030
--- Comment #1 from tbm at cyrius dot com 2007-11-16 18:04 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
void sqlite3VdbeChangeP3 (const char *zP3)
{
freeP3 ((void *) *(char **) &zP3);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34122
--- Comment #4 from us15 at os dot inf dot tu-dresden dot de 2007-11-16
18:58 ---
The workaround fixes my build problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34110
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-16 18:33 ---
Mine. Still wrong on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2007-11-16 18:03 ---
(In reply to comment #2)
> I once found a page, where a very important person in the Linux world (cannot
> remember who now, Linux Toward probably) complained about the lack of inlining
> in linux-Kernel, that there were no
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-16 18:17 ---
Confirmed. Still broken on the 4.1 and 4.2 branches. Wrong types on the
comparison:
D.1530_7 == 0B
(gdb) call debug_tree (expr)
unit size
align 8 symtab 0 alias set -1 precision 1 min max >
I get the following ICE with current trunk. This didn't happen
with a compiler from trunk on 2007-10-27.
(sid)[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O
sqlitebrowser-vdbeaux.c
sqlitebrowser-vdbeaux.c: In function 'sqlite3VdbeChangeP3':
sqlitebrowser-vdbeaux.c:6: internal compiler e
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-16 18:01 ---
(In reply to comment #2)
> Whaow, I have posted this report for a while...!!!
I guess this report fell through the cracks of bugzilla. Reporting the status
on new versions of GCC would have probably helped.
> But Sin
--- Comment #2 from niklas dot holsti at tidorum dot fi 2007-11-16 18:07
---
(In reply to comment #1)
> Seems like a good idea.
I think so, too.
> I do wonder if perhaps a new flag that just disables range checking to get the
> 'old' behavior would be warranted?
Yes, that would defin
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-16 18:00 ---
Note that for completely inlining kernels you can use the
__attribute__((flatten))
on the *calling* function. Usually with expression templates that is the
function
containing the loops, like
void __attribute__((fl
--- Comment #63 from pault at gcc dot gnu dot org 2007-11-16 17:01 ---
I suppose that, after all, I should reassign myself.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pcarlini at suse dot de 2007-11-16 15:12 ---
3.4.x is not maintained anymore. Otherwise, -pedantic is enough.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #2 from laurent at ient dot rwth-aachen dot de 2007-11-16
17:46 ---
(In reply to comment #1)
> What does -Winline say?
>
> Have you tried with always_inline? Example:
>
> /* Prototype. */
> inline void foo (const char) __attribute__((always_inline));
>
Whaow, I
--- Comment #2 from peter_foelsche at agilent dot com 2007-11-16 16:42
---
the attached piece of source code does exhibit the compiler problem with the
new compiler.
When compiling using -O3 the code works fine. When compiling using -g the bug
happens.
Some temporary objects are being c
--- Comment #6 from joseph at codesourcery dot com 2007-11-16 16:53 ---
Subject: Re: [4.1/4.2/4.3 Regression] spurious exceptions
with -ffloat-store
The failure still appears with a compiler from revision 130227, after the
patch for PR 34099 was committed.
--
http://gcc.gnu.org/
--- Comment #20 from jakub at gcc dot gnu dot org 2007-11-16 14:31 ---
Does the problem go away if you
mv include/*-*-*/bits/stdc++.h.gch{,bad}
and recompile the test? If yes, can you please check with -fdump-tree-all
at which pass the dumps start to differ between compilation with stdc
--- Comment #3 from peter_foelsche at agilent dot com 2007-11-16 16:45
---
We tested this only for the 64bit version.
I don't know if this happens for the 32bit version.
The operating system is LINUX:
Linux bonfire 2.4.21-47.0.1.EL #1 SMP Fri Oct 13 17:51:36 EDT 2006 x86_64
x86_64 x86_
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-16 16:58 ---
Introduced by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129596
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
When compiling with -O3 everything is fine.
When compiling with -g this pointer passed to constructors and destructors
don't line up.
I guess the this pointer passed to the constructor is bogus.
--
Summary: wrong this pointer passed to constructor of temporary
obje
--- Comment #14 from manu at gcc dot gnu dot org 2007-11-16 16:17 ---
Is there any difference in the standard behaviour between printf("%s", NULL)
and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
but neither puts(NULL) nor fprintf(stdout, "%s", NULL) do?
Any
--- Comment #1 from peter_foelsche at agilent dot com 2007-11-16 16:38
---
Created an attachment (id=14564)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14564&action=view)
test.cpp
contains a main function at the end which calls printf() with some temporary
objects. I put printf
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-11-16 14:40
---
Subject: Bug 33870
Author: rguenth
Date: Fri Nov 16 14:40:04 2007
New Revision: 130231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130231
Log:
2007-11-16 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-16 15:42 ---
I am tempted to close this since it is almost impossible to debug. We would
need an exact copy of your setup (for example, which files you touched and
which ones you didn't since last built). And still this may be due t
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-16 15:59 ---
Is this still valid?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
1 - 100 of 129 matches
Mail list logo
