I'm investigating an ICE on m68k architecture. I'm not quite sure what
is the right way to fix the bug so I welcome any feedback on the below
analysis.
Compilation fails on the assert in dwarf2out.c:based_loc_descr():
cut
/* We only use frame base when we're sure we're talking about the
Amker.Cheng wrote:
Hi :
I'm puzzled when looking into speculative scheduling in gcc, the 4.2.4 version.
First, I noticed the document describing IBM haifa instruction
scheduler(as PowerPC Reference Compiler Optimization Project).
It presents that the instruction motion from bb s(dominated by
On Sun, Sep 20, 2009 at 3:43 PM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
Amker.Cheng wrote:
Hi :
I'm puzzled when looking into speculative scheduling in gcc, the 4.2.4
version.
First, I noticed the document describing IBM haifa instruction
scheduler(as PowerPC Reference Compiler
On Sun, 20 Sep 2009, Dave Korn wrote:
Richard Guenther wrote:
The trunk is in Stage 1. Stage 1 will end on Sep 30th. After Stage 1
Stage 3 follows with only bugfixes and no new features allowed.
Stage 3 will end Nov 30th.
I'll answer your and Jacks question together.
I don't
On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
I'm investigating an ICE on m68k architecture. I'm not quite sure what is
the right way to fix the bug so I welcome any feedback on the below
analysis.
Compilation fails on the assert in
G++ currently accepts the following code:
char *
alloc(unsigned a, unsigned b)
{
typedef char array[a];
return **(new array[b]);
}
Is this intentional? The equivalent new char[a][b] is rejected (as
required by the C++ standard).
Richard Guenther wrote:
On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
...
This code uses eliminate_regs(), which implicitly assumes reload_completed
as it uses reg_eliminate[], which assumes that frame_pointer_needed is
properly set, which happens in ira.c.
On Sun, Sep 20, 2009 at 1:18 PM, Maxim Kuvyrkov ma...@codesourcery.com wrote:
Richard Guenther wrote:
On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov ma...@codesourcery.com
wrote:
...
This code uses eliminate_regs(), which implicitly assumes
reload_completed
as it uses reg_eliminate[],
On Sun, 20 Sep 2009, Dave Korn wrote:
Richard Guenther wrote:
Note that Stage 3 isn't that strict as it may sound. Maintainers have
quite amount of flexibility deciding what is considered a bug and thus
a bugfix during Stage 3 (note that Stage3 is _not_ only for regression
fixes).
Richard Guenther wrote:
On Sun, 20 Sep 2009, Dave Korn wrote:
BTW, why don't we call this more-flexible-stage-3 stage 2 any more? It
sounds a lot like the way that's still described on develop.html.
Because New functionality may not be introduced during this period. is
still true for
As commented to my last status report develop.html does not reflect
reality anymore. The following tries to adjust it carefully in
this respect.
Ok for www?
Thanks,
Richard.
2009-09-20 Richard Guenther rguent...@suse.de
* develop.html: Adjust to reflect recent practice.
Index:
I wonder if there would be at least a theoretical support by the
developers to a proposal for volatile bitfields:
When a HW register (thus most likely declared as volatile) is defined as
a bitfield, as far as I know gcc treats each bitfield assignment as a
separate read-modify-write operation.
Hi :
In function new_ready, it calls to min_insn_conflict_delay with
min_insn_conflict_delay (curr_state, next, next).
But the function's comments say that it returns minimal delay of issue of
the 2nd insn after issuing the 1st in given state.
Why the last two parameter for the call are both
Richard Guenther wrote:
* develop.html: Adjust to reflect recent practice.
TYVM :)
cheers,
DaveK
reg.field1 = val1, reg.field2 = val2;
would then turn into fetch, mask with a combined mask of field1 and
field2, or val1, or val2, store.
You can also do the RMW yourself: declare the register volatile, but not
the fields of it, and copy in/out of the register manually.
volatile struct
Paolo Bonzini wrote:
Is it a completely brain-dead idea?
If I understood it correctly, it would not be standard compliant.
But it's an extension, so I don't see that is an issue of itself.
Paolo
Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
looks like a pessimisation especially if the constants are small, since
STRICT_LOW_PART must not touch the high part. Is there a way for the
backend to
Richard Guenther wrote:
2009-09-20 Richard Guenther rguent...@suse.de
* develop.html: Adjust to reflect recent practice.
OK.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
looks like a pessimisation especially if the constants are small, since
On 09/20/2009 06:31 PM, Richard Guenther wrote:
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwabsch...@linux-m68k.org wrote:
Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
looks like a pessimisation
All,
I have been debugging AVR port to see why we fail to match so many bit
test opportunities.
When dealing with longer modes I have come across a problem I can not solve.
Expansion in RTL for a bit test can produce two styles.
STYLE 1 Bit to be tested is NOT LSB (e.g. if ( longthing
Richard Guenther wrote:
As commented to my last status report develop.html does not reflect
reality anymore. The following tries to adjust it carefully in
this respect.
h3Schedule/h3
-pDevelopment on our main branch will proceed in three stages. Each
-stage will be two months in
On Sun, 20 Sep 2009, Theodore Papadopoulo wrote:
Richard Guenther wrote:
As commented to my last status report develop.html does not reflect
reality anymore. The following tries to adjust it carefully in
this respect.
h3Schedule/h3
-pDevelopment on our main branch will proceed
On Sun, 20 Sep 2009, Zolt??n K??csi wrote:
I wonder if there would be at least a theoretical support by the
developers to a proposal for volatile bitfields:
It has been proposed (and not rejected, but not yet implemented) that
volatile bit-fields should follow the ARM EABI specification (on
Snapshot gcc-4.3-20090920 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090920/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Si gasolina gratis para su automovil
desde un 17% por cada tanque de combustible
con el original maxifuel
www.maxifuel.com.mx
estamos en busca de distribuidores
unete a la familia maxifuel
normamaxif...@gmail.com
utilidades garantizadas plazas disponibles
On Sun, 20 Sep 2009, Joseph S. Myers wrote:
On Sun, 20 Sep 2009, Zolt??n K??csi wrote:
I wonder if there would be at least a theoretical support by the
developers to a proposal for volatile bitfields:
It has been proposed (and not rejected, but not yet implemented) that
volatile
Building rev. 151881 fails with
../../../gcc/libgcc/../gcc/libgcc2.c: In function __powisf2:
../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in
convert_regs_1, at reg-stack.c:3052
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #39 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-09-20 06:30 ---
The updated patch fixes align-counterexample1.c, but not
align-counterexample2.c. Note that you must align the stack for all functions
that have some SSE operations, because you never know if
Building rev. 151881 fails with
../../../gcc/libgcc/../gcc/libgcc2.c: In function __powisf2:
../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in
convert_regs_1, at reg-stack.c:3052
Please submit a full bug report,
with preprocessed source if appropriate.
See
Building rev. 151881 fails with
../../../gcc/libgcc/../gcc/libgcc2.c: In function __powisf2:
../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in
convert_regs_1, at reg-stack.c:3052
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #2 from aanisimov at inbox dot ru 2009-09-20 07:18 ---
(In reply to comment #1)
Why do you open 3 bug reports for the same problem?
Sorry, some bug with my browser.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41410
--- Comment #11 from developer at sandoe-acoustics dot co dot uk
2009-09-20 08:00 ---
see my comment #10 on PR41395 and note that this bug also shows on
powerpc-apple-darwin9.
It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure about the
likelihood of a straight
--- Comment #13 from cgd at gcc dot gnu dot org 2009-09-20 08:08 ---
Subject: Bug 28435
Author: cgd
Date: Sun Sep 20 08:08:06 2009
New Revision: 151894
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151894
Log:
[gcc/testsuite/ChangeLog]
2009-09-20 Chris Demetriou
--- Comment #14 from cgd at gcc dot gnu dot org 2009-09-20 08:10 ---
HJ, I believe I've fixed the tests now:
PASS: gcc.dg/cpp/missing-header-MD.c (test for warnings, line )
PASS: gcc.dg/cpp/missing-header-MD.c (test for warnings, line )
PASS: gcc.dg/cpp/missing-header-MD.c (test for
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-20 09:19 ---
*** This bug has been marked as a duplicate of 41395 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-09-20 09:19
---
*** Bug 41414 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-20 09:20 ---
*** This bug has been marked as a duplicate of 41395 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-09-20 09:20
---
*** Bug 41415 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-20 09:20 ---
*** This bug has been marked as a duplicate of 41395 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-09-20 09:20
---
*** Bug 41413 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-20 09:24 ---
Fixed on trunk at revision 151895.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from developer at sandoe-acoustics dot co dot uk
2009-09-20 09:38 ---
(In reply to comment #11)
see my comment #10 on PR41395 and note that this bug also shows on
powerpc-apple-darwin9.
It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure about the
--- Comment #19 from developer at sandoe-acoustics dot co dot uk
2009-09-20 09:42 ---
applying
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01274.html
causes i686-apple-darwin9 to fail with the (long long) fault for all
--enable-checking=xx I've tried.
Thus, that fault seems separate
--- Comment #3 from lifeng at gcc dot gnu dot org 2009-09-20 10:47 ---
We should check if 2 data reference are with the same base object before
checking dependency.
This bug has been fix. Now has committed to Graphite branch.
http://gcc.gnu.org/viewcvs?view=revisionrevision=151801
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-20 11:12 ---
including PCH indirectly is not supported.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-09-20 11:14 ---
Indirectly including a PCH is invalid.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-20 11:22 ---
More proper bugreport is PR33980.
*** This bug has been marked as a duplicate of 33980 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-20 11:22 ---
*** Bug 30702 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36273
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-20 11:24 ---
(In reply to comment #3)
Will have to be tested again once PR 39886 is done with; hopefully, should
then
be gone.
As 39886 is fixed on trunk. Could you please verify if it was an duplicate of
39886?
Cheers,
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-20 11:25 ---
Invalid according to comment #2
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Priority|P3
-as
--enable-threads=po
six --enable-cpp --with-gmp=/usr/local --with-mpfr=/usr/local --enable-shared
Thread model: posix
gcc version 4.5.0 20090920 (experimental) (GCC)
configure:3003: $? = 0
configure:2992: /usr/users/jsg/src/obj/./gcc/xgcc
-B/usr/users/jsg/src/obj/./gcc/ -B/usr/gcc/i386-unknown
--- Comment #7 from jv244 at cam dot ac dot uk 2009-09-20 13:18 ---
Not easy to find a machine that old, but it works with 3.3.3 and it fails
already with 4.1.2. Pretty old regression thus [tested with the C code].
--
jv244 at cam dot ac dot uk changed:
What|Removed
Hi,
the following complete sample code shows different conversion behaviours
between fixed-point types and Float to fixed-point depending on whether the
expressions are static or not. In the static case, GNAT uses a conversion
strategy comparable to truncation, otherwise rounding is used.
I
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-09-20 14:05 ---
On the tree level we end up with the correct (but unfortunately unfolded)
main ()
{
int icon01;
bb 2:
if (label_001263 == label_001262)
goto bb 5 (label_001265);
else
goto bb 3 (label_001262);
--- Comment #9 from jv244 at cam dot ac dot uk 2009-09-20 14:18 ---
(In reply to comment #8)
Thus, this is a frontend issue with assigned goto (a deleted feature btw).
so just for my curiosity, is the C code thus invalid?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
I tried to build the current gcc-4.5.0 svn (rev. 151902)
It now failes for a few days with a segfault.
It happends if the ./gcc/xgcc is used, the broken down command is now:
LC_ALL=C gcc/xgcc -Bgcc -g -O2 -c gcc/libgcc2.i
./gcc/libgcc2.c: In function '__powixf2':
./gcc/libgcc2.c:1739:1: internal
[ ref: http://gcc.gnu.org/ml/gcc/2009-08/msg00085.html ]
libtool: link: /opt/gcc-tools/i686-pc-cygwin/bin/ar rc .libs/libgomp.lib
alloc.
o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o
ordered
.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-09-20 14:44
---
No, the C code is valid, but it's results depend on optimization level
(just like if you would compare the addresses of stack locals).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
--- Comment #1 from m4rkusxxl at web dot de 2009-09-20 14:44 ---
Created an attachment (id=18615)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18615action=view)
The file created with the xgcc and -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41417
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-20 14:57 ---
Created an attachment (id=18616)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18616action=view)
diffs in generated libtool files
This looks like it might be informative.
--
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-20 14:59 ---
Perhaps the two single most salient points from that diff:
# Is the compiler the GNU compiler?
-with_gcc=no
+with_gcc=yes
# Whether we are building with GNU ld or not.
-with_gnu_ld=no
+with_gnu_ld=yes
Did not
Starting program:
/users/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-jmr3904/tests/a/a85013b/a85013b
,.,. A85013B ACATS 2.5 88-01-01 00:00:00
A85013B CHECK THAT A SUBPROGRAM CAN BE RENAMED WITHIN ITS OWN BODY
AND THAT THE NEW NAME CAN BE USED IN A RENAMING
--- Comment #1 from joel at gcc dot gnu dot org 2009-09-20 15:20 ---
Should have included command line. This is for arch=r3900.
mips-rtems4.10-gnatmake --RTS=. -fstack-check -v -O -gnatws -O2
-I/users/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-jmr3904/support
a85013b.adb
--- Comment #13 from dominiq at lps dot ens dot fr 2009-09-20 15:24 ---
The culprit is indeed r151815. Reverting the change after having updated to
r151893 on i686-apple-darwin9 ( r151895 on powerpc-apple-darwin9) allows a
successful bootstrap (currently building the libs on powerpc).
--- Comment #2 from laurent at guerby dot net 2009-09-20 15:33 ---
Ada code in s-taprop-posix.adb
Result := pthread_attr_init (Attributes'Access);
pragma Assert (Result = 0 or else Result = ENOMEM);
if Result /= 0 then
Succeeded := False;
return;
--- Comment #21 from dominiq at lps dot ens dot fr 2009-09-20 15:36 ---
In reply to comment #20
bootstrap also fails on OpenBSD/i386 when it used to work a week ago ie:
gcc version 4.5.0 20090913 (experimental) (GCC)
You may try to revert revision 151815 (see pr41405, the patch is in
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-09-20 15:39 ---
Subject: Bug 30789
Author: ghazi
Date: Sun Sep 20 15:39:22 2009
New Revision: 151904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151904
Log:
PR middle-end/30789
* builtins.c (do_mpc_arg2):
--- Comment #3 from joel at gcc dot gnu dot org 2009-09-20 15:56 ---
The debug information is weak since optimization hides a lot. But it looks
like Page_Size might be 0.
(gdb) c
Continuing.
,.,. A85013B ACATS 2.5 88-01-01 00:00:00
A85013B CHECK THAT A SUBPROGRAM CAN BE RENAMED
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-09-20 16:08 ---
Fixed, but depends on hard-requiring MPC.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
We have simple source file: file.64.cpp
int main()
{
#ifdef SOME64
printf(64\r\n);
#else
printf(32\r\n);
#endif
return 0;
}
So. If we build file with that command
$CC -DSOME64 -I../../common/src -O0 -g3 -Wall -c systemcontroller.64.cpp
then SOME64 are undefined in file(../../common/src is valid
--- Comment #8 from ghazi at gcc dot gnu dot org 2009-09-20 16:21 ---
Current GCC mainline incorporates all the complex math functions included with
mpc-0.7. All that's left are the complex arc functions which are expected in
a future MPC release, possibly mpc-0.8.
--
ghazi at gcc
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2009-09-20
16:22 ---
Reverting r151815 also eliminates the bootstrap breakage on
x86_64-apple-darwin10. Nice catch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-09-20
16:24 ---
You might want to change the Summary here to [4.5 Regression] Bootstrap broken
by r151815 on *-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--- Comment #4 from laurent at guerby dot net 2009-09-20 16:28 ---
from s-osinte-rtems.adb:
function Get_Page_Size return size_t is
begin
return 0;
end Get_Page_Size;
May be this value wasn't used before...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41419
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-09-20 16:36
---
As far as I understand the problem, I do not see why tools not designed to
accept dwarf_version 4 can be blamed for that (it would be like blaming the
CD player in my car for not reading MP3 CDs).
But you
--- Comment #3 from marcus at jet dot franken dot de 2009-09-20 16:39
---
hmm, if I rerun: configure --enable-lto --enable-languages=c it works
perhaps the auto reconfig logic was broken a bit
--
marcus at jet dot franken dot de changed:
What|Removed
--- Comment #6 from joel at gcc dot gnu dot org 2009-09-20 16:46 ---
Every s-osinte*.ads which has Get_Page_Size includes a comment about 0 being
valid to return and indicate that Page_Size does not matter.
-- Returns the size of a page, or 0 if this is not relevant on this target
--- Comment #7 from charlet at gcc dot gnu dot org 2009-09-20 16:58 ---
Get_Page_Size should indeed now not be a dummy value and cannot be 0.
I'll take care of updating the comments in s-osinte*.ads when I get a chance
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41419
--- Comment #8 from laurent at guerby dot net 2009-09-20 16:59 ---
Given s-taprop-posix code it's obvious that Page_Size cannot be zero:
-- Round stack size as this is required by some OSes (Darwin)
Adjusted_Stack_Size := Adjusted_Stack_Size + Page_Size - 1;
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2009-09-20
17:02 ---
(In reply to comment #16)
As specified they should ignore dwarf codes they do not understand, not assert
on them. Please if you care report this issue to apple (it's probably enough
to send them along
--- Comment #6 from toon at moene dot org 2009-09-20 17:03 ---
It seems we have exhausted the arguments in this case.
The best cause of action seems to be to document that gfortran won't allow to
open dangling symlinks with STATUS='NEW'.
This bug report remains open until that is
--- Comment #11 from jvdelisle at verizon dot net 2009-09-20 17:04 ---
Subject: Re: [4.3/4.4/4.5 Regression] miscompilation of
goto/label using code
rguenth at gcc dot gnu dot org wrote:
but instead it should have used a computed goto, like
C.0 = { __label_001262,
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-09-20 17:09
---
Yes that's ok. What is not ok is to compare addresses of labels and to rely
on different labels having different addresses.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
--- Comment #9 from joel at gcc dot gnu dot org 2009-09-20 17:12 ---
Thanks for the quick response. I am in the process of adding getpagesize() to
RTEMS. We already had sysconf(_SC_PAGESIZE) and returned 4096. I will change
the s-osinte-rtems.ad* to use that and post a patch when it
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-20 17:26 ---
*** Bug 40364 has been marked as a duplicate of this bug. ***
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-09-20 17:26 ---
I tested your attachment against patched trunk and fix of PR/39886 resolved it.
So I mark it as duplicate.
*** This bug has been marked as a duplicate of 39886 ***
--
ktietz at gcc dot gnu dot org changed:
--- Comment #2 from smal dot root at gmail dot com 2009-09-20 17:30 ---
I correct clock, restart Xorg and everything work... Its good. Sorry
--
smal dot root at gmail dot com changed:
What|Removed |Added
--- Comment #22 from hjl at gcc dot gnu dot org 2009-09-20 18:00 ---
Subject: Bug 41395
Author: hjl
Date: Sun Sep 20 17:59:44 2009
New Revision: 151905
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151905
Log:
2009-09-20 H.J. Lu hongjiu...@intel.com
PR
--- Comment #40 from howarth at nitro dot med dot uc dot edu 2009-09-20
18:27 ---
Is this the location of the additional epilogue notes being added in r147995?
@@ -8637,7 +8757,17 @@
+ frame.nregs * UNITS_PER_WORD
The C++0x standard draft defines a trivial type as one that has trivial default
construct, copy constructor, copy assignment operator and destructor. g++ from
the current trunk, however, classifies types without default constructor as
trivial, meaning that the following code does not compile:
--- Comment #40 from hjl dot tools at gmail dot com 2009-09-20 18:43
---
Created an attachment (id=18617)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18617action=view)
An updated patch for gcc trunk
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #41 from hjl dot tools at gmail dot com 2009-09-20 18:44
---
Created an attachment (id=18618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18618action=view)
An updated patch for gcc 4.4
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #42 from hjl dot tools at gmail dot com 2009-09-20 18:44
---
(In reply to comment #39)
The updated patch fixes align-counterexample1.c, but not
align-counterexample2.c. Note that you must align the stack for all functions
that have some SSE operations, because you never
--- Comment #1 from paolo dot carlini at oracle dot com 2009-09-20 19:11
---
Jason, can you have a look to this issue? I believe submitter is right. Should
we use TYPE_HAS_TRIVIAL_DFLT instead? Note sure about
TYPE_HAS_TRIVIAL_INIT_REF, TYPE_HAS_TRIVIAL_ASSIGN_REF, and
--- Comment #2 from m4rkusxxl at web dot de 2009-09-20 19:18 ---
When I overwrite by global CFLAGS with just -march=opteron (without the
-O2) it compiles fine.
Is optimization not supported or is it a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41417
--- Comment #3 from hjl dot tools at gmail dot com 2009-09-20 19:37 ---
*** This bug has been marked as a duplicate of 41395 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #23 from hjl dot tools at gmail dot com 2009-09-20 19:37
---
*** Bug 41417 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
1 - 100 of 140 matches
Mail list logo
