--- Comment #4 from fang at csl dot cornell dot edu 2007-03-27 08:52
---
Poor vector, being disrespected as a second-class container once again...
:P
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
-
--- Comment #6 from prakash at punnoor dot de 2007-03-27 08:35 ---
Well, you commited the fix for the trunk, ie 4.2? But what about 4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31361
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-27 07:28 ---
I cannot reproduce this with powerpc64-linux-gnu configured to default to
32bits (that is --with-cpu=default32).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-27 07:04 ---
vector should really go away. It is not really a container at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from ian at airs dot com 2007-03-27 06:56 ---
Fixed on mainline and 4.2 branch.
--
ian at airs dot com changed:
What|Removed |Added
Status|ASSI
--- Comment #7 from ian at gcc dot gnu dot org 2007-03-27 06:47 ---
Subject: Bug 31345
Author: ian
Date: Tue Mar 27 06:46:56 2007
New Revision: 123254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123254
Log:
./:
PR tree-optimization/31345
* tree-vrp.c (extract_
--- Comment #34 from mmitchel at gcc dot gnu dot org 2007-03-27 04:31
---
Just a confirmation that I see this test failing with GCC 4.1 on Solaris as
well. As Eric says in Comment #11, the symptoms are that, in host-solaris.c
the first call to mmap succeeds (but at the wrong address).
--- Comment #2 from gcc at severeweblint dot org 2007-03-27 04:20 ---
Created an attachment (id=13293)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13293&action=view)
patch
This patch fixes all the problems in the cheapest possible way. With it the
attached testcase succeedds. It
--- Comment #1 from gcc at severeweblint dot org 2007-03-27 04:08 ---
Created an attachment (id=13292)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13292&action=view)
testcase
This little program pushes some of the boundary cases. It ought to print
nothing and exit cleanly. Curre
Pre-4.0, vector had a bunch of nasty error cases when resizing overflowed a
size_t. Change 89377 fixed some of them. But
1) vector's copy (yuck) of the relevant functions weren't updated
2) vector's max_size is incorrect. currently it is set to the maximum
size_t. but because vector's iterators a
Here's an example:
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/libgomp/testsuite/libgomp.c++/copyin-1.C
-B/test/gnu/gcc/objdir/
hppa64-hp-hpux11.11/./libgomp/
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libg
omp -I/test/gnu/gcc/gcc/libgomp/test
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-27 03:09
---
I can confirm this issue, using both a GCC 4.1.x compiler and an FSF mainline
compiler on the most current (late 2006) release of Solaris 10. Sun's version
of GCC (based on GCC 3.4.3) as installed in /usr/sfw/bin/
--- Comment #1 from tromey at gcc dot gnu dot org 2007-03-27 02:44 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #5 from dirtyepic at gentoo dot org 2007-03-27 01:49 ---
I was referring to what the user gets to experience at runtime.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
--- Comment #5 from rth at gcc dot gnu dot org 2007-03-27 01:37 ---
You can shift the 32-bit portions individually. But your test case will now
result in 0,0,0,0 for all optimization levels, since the shift count is taken
from the entire xmm register. In this case, since there is an 8
--- Comment #4 from rth at gcc dot gnu dot org 2007-03-27 01:30 ---
Subject: Bug 31361
Author: rth
Date: Tue Mar 27 01:30:32 2007
New Revision: 123250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123250
Log:
PR target/31361
* config/i386/i386.c (IX86_BUILTIN_PS
--- Comment #3 from spark at gcc dot gnu dot org 2007-03-27 00:56 ---
# cat -n t.c
1 typedef __attribute__((deprecated)) int foo;
2 typedef
3 struct
4 __attribute__((deprecated))
5 bar1
6 {
7foo baz;
8 }
9 bop1;
--- Comment #5 from pcarlini at suse dot de 2007-03-26 23:24 ---
Yes, as I said, we need a better reproducer, that is a testcase that on most of
the current x86-linux or x86-64-linux machines behaves as you are reporting: if
you want to help you should look for a recent machine (e.g., gl
--- Comment #4 from gregoryk at edifecs dot com 2007-03-26 23:13 ---
Ok. Can I help you somehow?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #13 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 23:05 ---
Subject: Re: [4.2/4.3 Regression] rtl loop invariant is broken
> Zdenek, what is the size heuristic for anyway? For powerpc, the current
> heuristic tells the compiler not to move any simple
--- Comment #5 from pcarlini at suse dot de 2007-03-26 22:56 ---
Fixed for 4.3.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from paolo at gcc dot gnu dot org 2007-03-26 22:55 ---
Subject: Bug 30500
Author: paolo
Date: Mon Mar 26 22:55:19 2007
New Revision: 123239
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123239
Log:
2007-03-26 Paolo Carlini <[EMAIL PROTECTED]>
PR c++/30
--- Comment #3 from paolo at gcc dot gnu dot org 2007-03-26 22:55 ---
Subject: Bug 30500
Author: paolo
Date: Mon Mar 26 22:55:03 2007
New Revision: 123238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123238
Log:
2007-03-26 Paolo Carlini <[EMAIL PROTECTED]>
PR c++/30
--- Comment #3 from pcarlini at suse dot de 2007-03-26 22:52 ---
Ok, but before we take any further action we badly need a better reproduce: on
any up to date x86 and x86-64 linux machine I tried, your testcase segfault
immediately both for unsigned short and for char (and the workaround
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #6 from ian at gcc dot gnu dot org 2007-03-26 22:43 ---
Subject: Bug 31345
Author: ian
Date: Mon Mar 26 22:43:30 2007
New Revision: 123237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123237
Log:
./:
PR tree-optimization/31345
* tree-vrp.c (extract_
--- Comment #12 from steven at gcc dot gnu dot org 2007-03-26 22:43 ---
Zdenek, what is the size heuristic for anyway? For powerpc, the current
heuristic tells the compiler not to move any simple moves:
1) An invariant with a gain of 0 will not be moved.
2) gain = comp_cost - size_cost
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #11 from steven at gcc dot gnu dot org 2007-03-26 22:36 ---
And of course the hack doesn't actually work :-) But it's still just a
heuristics tweak what we need here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #10 from steven at gcc dot gnu dot org 2007-03-26 22:33 ---
Just a small heuristics problem. This could be fixed by giving insns to move
with comp_cost - size_cost == 0 in gain_for_invariant a small gain anyway. Or
maybe comp_cost should overrule size_cost.
Just as a demon
--- Comment #2 from gregoryk at edifecs dot com 2007-03-26 22:28 ---
Though the problem from bug 25956 looks same the instantiating didn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 22:27 ---
3.2.3 produced:
.L6:
slwi 0,9,2
add 9,9,5
cmpw 0,9,4
stwx 11,3,0
bgelr- 0
b .L6
While 4.1.0 and above produces:
.L4:
add 9,9,5
stw 10,-4(3)
add
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-03-26 22:18
---
Adding Thomas to cc.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-26 22:17 ---
This is still a 4.2 regression.
4.2 produces:
.L2:
li 0,100
stwx 0,9,3
addi 9,9,4
bdnz .L2
blr
While 4.1 produces:
.L2:
stwx 0,9,3
addi 9,9,4
bdnz .L2
--- Comment #8 from steven at gcc dot gnu dot org 2007-03-26 22:13 ---
Re. comment #5
Andrew, stop spreading nonsense. Other compilers do take register pressure
into account. In fact, they do so much better than GCC usually does. (In GCC
you can't do it well because instructions are
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-26 22:11 ---
Plus I just tested the 4.2 branch and it is broken there also, G.
Sorry for finding this late in the release cycle but I guess nobody really
looked at the code quality after loop.c was turned off and rtl
--- Comment #1 from pcarlini at suse dot de 2007-03-26 22:10 ---
Seems the same as libstdc++/25956. Can you try whether instantiating the string
class at global scope works for you too:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00162.html
???
--
http://gcc.gnu.org/bugzilla/show
--- Comment #2 from pcarlini at suse dot de 2007-03-26 22:08 ---
The message to the libstdc++ list:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00155.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25956
--- Comment #34 from jvdelisle at gcc dot gnu dot org 2007-03-26 21:55
---
Regarding comment 24 and 32.
I have that downloaded and tried to compile and there are duplications of
subroutines and multiple main programs. As I get time, I intend to get it
sorted out and add it to my test
Main application dynamically loads shared library and uses function from
library to fill out string. If basic_string or basic_string are
used then no problem observed. In case of basic_string
application aborts (MALLOC_CHECK_=2) with message
*** glibc detected *** free(): invalid pointer: 0x0
--- Comment #4 from mesti_mudam at yahoo dot com 2007-03-26 21:49 ---
ive no idea which part of the standard should imply/allow this. if one replaces
"typename T::privIC * priv" with "T * priv", its valid and it compiles. I
thought T::privC is equally accessible & 'incomplete' as T itsel
--- Comment #3 from dj at redhat dot com 2007-03-26 21:36 ---
30972 is Windows, this is DJGPP - different operating systems.
Are you using the stock 2.03 files, or the 2.04 (beta) files? There are known
incompatibilities in XP and Vista that require the 2.04 builds of the GNU
tools, so
--- Comment #2 from david at luyer dot net 2007-03-26 21:27 ---
Two other related cases which generate warnings. I'm not sure
which is the correct syntax to mark a field deprecated, but
both are currently generating warnings, and marking a field
which uses a deprecated type as deprecate
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-03-26 21:21
---
You supposed to mark all functions which you don't want inlined as noinline.
that is what the noinline attribute is there for. The inliner is just too
smart that is all. If you want a dumber inliner fine, but do
--- Comment #42 from manu at gcc dot gnu dot org 2007-03-26 20:48 ---
Created an attachment (id=13291)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13291&action=view)
version 2 of fixtestsuite script
This new version of the script makes more automatic fixes.
--
manu at gcc do
--- Comment #5 from bangerth at dealii dot org 2007-03-26 20:48 ---
Yup, Andrew is right.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC
--- Comment #3 from bangerth at dealii dot org 2007-03-26 20:46 ---
(In reply to comment #2)
> well, priv is a pointer..
What I really meant was a typedef:
template struct Base {
typedef typename T::X X;
};
struct A : Base
{
typedef int X;
};
--- Comment #17 from bangerth at dealii dot org 2007-03-26 20:44 ---
*** Bug 31330 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--
--- Comment #2 from bangerth at dealii dot org 2007-03-26 20:44 ---
Yes, indeed.
*** This bug has been marked as a duplicate of 27102 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--
--- Comment #14 from hjl at lucon dot org 2007-03-26 20:41 ---
This isn't a real patch. But it seems to work on the testcase.
--- i386.md.dfp 2007-03-24 12:21:45.0 -0700
+++ i386.md 2007-03-26 12:30:21.0 -0700
@@ -1850,6 +1850,59 @@
""
"ix86_expand_move (DImode
--- Comment #15 from eweddington at cso dot atmel dot com 2007-03-26 20:22
---
FWIW, I agree with the OP. This will place a burden on users who work with
embedded systems such as the AVR. Special sections are sometimes needed in the
AVR to place code into a special bootloader area that
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-26 20:04
---
The build failure is still a regression, no matter which you look at it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #12 from hjl at lucon dot org 2007-03-26 19:56 ---
(In reply to comment #11)
> The ICE is still a bug which needs to be fixed Plus this is still a
> regression.
>
Failing to compile this code isn't a regression since the same code always
fails with gcc 4.2 and 4.3 when DFP
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 19:42 ---
Confirmed, the C front-end also gives the warning.
[EMAIL PROTECTED]:~$ ~/x86-local-fsf/bin/gcc t.c -S
t.c:4: warning: 'foo' is deprecated
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-03-26 19:39
---
The ICE is still a bug which needs to be fixed Plus this is still a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When a deprecated type is used in a struct which is itself deprecated, we
should not warn. That would be consistent with the current behaviour of not
warning about applying a deprecated type to a deprecated variable.
Test case:
typedef __attribute__((deprecated)) int foo;
typedef __attribute__((
--- Comment #10 from hjl at lucon dot org 2007-03-26 19:30 ---
I think dfp should be disabled by default on x86. We are missing patterns
for "movsd", "movdd", and maybe "movtd".
--
hjl at lucon dot org changed:
What|Removed |Added
-
--- Comment #2 from tromey at gcc dot gnu dot org 2007-03-26 19:27 ---
This seems reasonable to me.
Could you write a ChangeLog entry and submit the patch to
[EMAIL PROTECTED]
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rth at gcc dot gnu dot org 2007-03-26 19:14 ---
Confirmed. We've modeled the instruction incorrectly; it takes the shift
count from the entire 128-bit xmm register, not the low 32 or 8 bits.
--
rth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 19:09 ---
I could reproduce this with "4.0.4 20060622" but it works on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
--- Comment #2 from gr at collax dot com 2007-03-26 19:03 ---
(In reply to comment #1)
> Works for me.
Hm. Just to be completely sure, my source archive gcc-4.0.4.tar.bz2 has md5sum
8970debbc55bea85ee80961d733080f0, as two other copies fetched from different
mirrors. I compiled it on tw
--- Comment #14 from thutt at vmware dot com 2007-03-26 18:54 ---
> Why do you think sections are special?
> GCC does not know if a section is special or not and it really should not
> know.
I don't necessarily think that sections are 'special', but since gcc
has the capability to chan
--- Comment #9 from hjl at lucon dot org 2007-03-26 18:37 ---
Any tuning target doesn't set x86_accumulate_outgoing_args will fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
--- Comment #5 from ian at airs dot com 2007-03-26 18:27 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 123218)
+++ tree-vrp.c (working copy)
@@ -1982,10 +1982,18 @@ extract_range_from_binary_e
--- Comment #6 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 18:18 ---
Subject: Re: [4.3 Regression] rtl loop invariant is broken
> > I would agree, if we had RA capable of that (which I am not quite sure
> > whether we do or not, although this seems simple enoug
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-26 18:10
---
Why do you think sections are special?
GCC does not know if a section is special or not and it really should not know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-26 18:09 ---
> I would agree, if we had RA capable of that (which I am not quite sure
> whether we do or not, although this seems simple enough), or better,
> RA doing better job under high register pressure.
Then how do you exp
--- Comment #10 from sylvain dot pion at sophia dot inria dot fr
2007-03-26 18:03 ---
Let me mention that this is against 4.2. The trunk works well for me.
I tried several times during March (including today), and the bug is still
here.
Note that varrying the conditions slightly (even
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2007-03-26 18:00 ---
Subject: Re: [4.3 Regression] rtl loop invariant is broken
> > I guess the cost of loading zero is cheaper then?
>
> Cheaper than loading 0xDEADBEEF but not cheap enough not to pull out of th
--- Comment #4 from ian at airs dot com 2007-03-26 17:57 ---
I'm continuing to look into the best way to avoid the compiler crash. I want
to note that this code is being clobbered by undefined signed overflow.
Computing (19780211 + [-128,127]) * 43321879 is always going to overflow, so
--- Comment #12 from thutt at vmware dot com 2007-03-26 17:46 ---
I respectfully submit that I think you guys are missing the point.
The problem isn't that the compiler is inlining functions which
are called once, the problem is that the compiler is inlining a
function which
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-26 17:35 ---
Even if this MEM is ok, we still get bad results as we have *(a+b-4) inside the
loop now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
When the last record written to a direct access file is shorter than the record
length of the file, gfortran truncates the record. The following test program
produces a file whose length is 1 when it should be 10.
PROGRAM test
OPEN (76, FILE="test.txt", ACCESS="DIRECT", STATUS="NEW", RECL=10)
WRIT
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-26 17:18 ---
> It does silently crash, for all intents and purposes.
No, it is not silent at all, it warns loudly (you cannot turn off the warning
except by using -w).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
Right now gcj will make a vtable slot for a non-static private method.
We speculate that this is done for CNI.
However, there's no point to a private method having a vtable slot,
since private methods are never inherited. Ideally both gcj and g++
would emit calls to private methods directly (not v
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-26 17:02
---
4.1.2 also inlines the other one, so that won't help. Still noinline will.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-26 16:58
---
And now there is already an option to stop this inlining static functions
called once.
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-finline_002dfunctions_002dcalled_002donce-507
--
pinskia at g
--- Comment #2 from tbm at cyrius dot com 2007-03-26 16:55 ---
Further reduced (-fPIC):
__subvsi3 ()
{
abort ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31364
--- Comment #33 from spark at gcc dot gnu dot org 2007-03-26 16:54 ---
(In reply to comment #31)
> Here is a new patch. I need someone to test on SPEC. It is very simple.
>
> Index: transfer.c
> ===
> *** transfer.c (rev
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from tbm at cyrius dot com 2007-03-26 16:51 ---
Reduced testcase, you need -fPIC:
struct _pthread_fastlock
{
}
pthread_mutexattr_t;
extern void abort (void) __attribute__ ((__nothrow__))
__attribute__ ((__noreturn__));
typedef int SItype __attribute__ ((mode (SI)));
__s
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-26 16:51 ---
> I guess the cost of loading zero is cheaper then?
Cheaper than loading 0xDEADBEEF but not cheap enough not to pull out of the
loop. All the "easy" (one instruction) constants are not pulled out.
Really I think r
--- Comment #62 from bonzini at gnu dot org 2007-03-26 16:50 ---
dataflow branch cannot complete this at -O3 -fno-tree-pre -fno-tree-fre
--
bonzini at gnu dot org changed:
What|Removed |Added
I get the following ICE during bootstrap on powerpc with current SVN (revision
123217):
(sid)227:[EMAIL PROTECTED]: ..build/powerpc-linux-gnu/64]
/home/tbm/build/gcc-snapshot-20070326/build/./gcc/xgcc
-B/home/tbm/build/gcc-snapshot-20070326/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnu
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-26 16:43 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31363
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-26 16:43 ---
This is one of the additional constraints given in 12.7.1 of the F95 standard:
A dummy argument, or a subobject thereof, shall not appear in
aspecification-expr
except as the argument to one of the intrinsic functions
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-26 16:28 ---
We inline static functions used once (special_function_0 in your testcase)
starting with the tree inliner which appeared in 3.4.0. So the "bug" is
present
in all releases starting from 3.4.0 and still present in mai
--- Comment #8 from thutt at vmware dot com 2007-03-26 15:57 ---
Furthermore,
4. By placing the code in a different section, I'm instructing the
the compiler to *not* put it in '.text'. By inlining it, it
places it in '.text' despite my instructions.
--
http://g
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-26 15:51 ---
Note that for your testcase even if you specify the noinline attribute the
function calls will be optimized away as the function calls do not have
side-effects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=313
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-26 15:47 ---
In the actual implementation from which this test case was derived,
the function *must* reside at a specific location in memory, but due
to the inlining, it does not. This causes failures in the
application.
You
--- Comment #5 from thutt at vmware dot com 2007-03-26 15:40 ---
I'm going to argue that comment #4 is incorrect.
1. This new behavior is a regression from previous versions of gcc.
2. The 4.1.1 compiler gets it right at -O0 and -O3. Previous
versions of gcc which we've been usi
--- Comment #9 from bangerth at dealii dot org 2007-03-26 15:17 ---
(In reply to comment #8)
> but I guess it could be possible at link time, as it is already the case
> for C symbols.
We also don't do that in C: if you have two functions of the same name defined
in two different .c fi
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-26 15:11 ---
If it is incorrect to inline a function you should specify that with
__attribute__((noinline)), I don't see why in general inlining a function which
out of line copy is in a special section is wrong.
--
rguenth a
gcc version 4.0.4
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/var/tmp
compiling with "-O" on input:
void
foo(unsigned long long c)
{
if (c & 0x8000)
puts("bug");
}
int
main(void)
{
foo(0x1ULL);
return 0;
}
produces "bug".
--- Comment #3 from thutt at vmware dot com 2007-03-26 15:09 ---
Created an attachment (id=13290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13290&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #2 from thutt at vmware dot com 2007-03-26 15:09 ---
Created an attachment (id=13289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13289&action=view)
original source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31362
--- Comment #1 from thutt at vmware dot com 2007-03-26 15:08 ---
Created an attachment (id=13288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13288&action=view)
Simple Script which will build the original C source
Simple Script which will build the original C source
--
http
gcc should never inline functions which have a 'section' attribute set
on them.
If the section is placed at a specific location in memory via a linker
script, then the function will not be placed into its correct address,
and the resultant executable is incorrect.
gcc 4.1.1 will inline static fun
--- Comment #3 from dirtyepic at gentoo dot org 2007-03-26 14:27 ---
All true. But this report is not about openssl, it's about GCC purposely going
out of it's way to break undefined code for no good reason. It does silently
crash, for all intents and purposes. I'm not saying that's n
1 - 100 of 113 matches
Mail list logo
