http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #2 from Eric Botcazou ---
The subject is very misleading, the alignment of constants is _not_ changed at
all, otherwise many things would have been broken. The only change pertains to
the internal alignment of initializers and cannot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #4 from Eric Botcazou ---
> I don't understand the comment "questionable optimization patterns".
I don't see much value in optimizing a memcpy to initialize a variable, it's
unlikely to be in a hot spot. I'd suggest adding 'const' to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31016
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
||2013-08-12
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou ---
I cannot reproduce:
=== acats tests ===
=== acats Summary ===
# of
||ebotcazou at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #3 from Eric Botcazou ---
The exception is correctly handled on modern systems (Linux, recent Darwin) so
this may be a bug in the unwinder. Older Darwins use an antiquated system
||2013-08-16
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Eric Botcazou ---
> I'm using GNU c++filt (C++ demangler), version 2.95.3.
What's the output of c++filt --v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58168
--- Comment #4 from Eric Botcazou ---
> Maybe the version is too old:
>
> ---
> [local@raymund6:~]>which c++filt
> /usr/local/bin/c++filt
> [local@raymund6:~]>c++filt --version
> GNU c++filt (C++ de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178
--- Comment #8 from Eric Botcazou ---
The configure line for the compiler is needed on Solaris as well.
|4.8.0
Last reconfirmed||2013-08-21
Component|middle-end |tree-optimization
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Summary|wrong
||2013-08-25
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Eric Botcazou ---
> OK, I see the emitted reference to 'operator delete', and I suspect I
> have an idea of
||2013-08-30
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou ---
Thanks for reporting the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #10 from Eric Botcazou -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #11 from Eric Botcazou ---
> "grep -R -static-libstdc++ gcc/ada" suggests that -static-libstdc++ only
> appears in a Changelog entry.
>
> also the gcc driver silently ignores -static-libstdc++.
>
> certainly, the -B options are passe
||2013-08-30
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou ---
What do you mean exactly? What's the difference with the default visibility?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
--- Comment #3 from Eric Botcazou ---
> Compare with this on amd64:
>
> > c++ -o plain.s -S conftest.cc
> > c++ -o shared.s -fPIC -shared -S conftest.cc
> > diff -u plain.s shared.s
> --- plain.s 2013-08-30 21:46:18.0 +0200
> +++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #13 from Eric Botcazou ---
Created attachment 30734
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30734&action=edit
Tentative fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #15 from Eric Botcazou ---
> As I was trying to say in earlier comments (and failing to be clear, I
> suppose), Darwin needs the library dirs as "-B" in addition to "-L", because
> we have to use spec substitution to access static libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #17 from Eric Botcazou ---
Author: ebotcazou
Date: Sun Sep 1 16:51:41 2013
New Revision: 202150
URL: http://gcc.gnu.org/viewcvs?rev=202150&root=gcc&view=rev
Log:
PR ada/58239
gnattools/
* Makefile.in (CXX_LFLAGS): New.
(T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2013-09-02
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Build|powerpc64-linux |powerpc*-linux
--- Comment #2 from Eric Botcazou ---
Likewise on PowerPC/Linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56382
--- Comment #4 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Sep 2 16:19:20 2013
New Revision: 202179
URL: http://gcc.gnu.org/viewcvs?rev=202179&root=gcc&view=rev
Log:
PR middle-end/56382
* expr.c (emit_move_complex): Do not move co
|NEW
Keywords||missed-optimization
Last reconfirmed||2013-09-02
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Summary
||2013-09-05
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Eric Botcazou ---
It's quite hard because the frame is laid out way before all the memory
accesses to the stack slot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295
--- Comment #5 from Eric Botcazou ---
> Therefore, we can conclude that the original case tried by the combiner is
> the best way to merge/reduce the redundant zero extension insn.
Yes and, although x86 is the dominant architecture, it shouldn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Target
||2013-09-07
CC||ebotcazou at gcc dot gnu.org
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
Severity|normal |blocker
--- Comment #1 from Eric Botcazou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58364
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
Summary|Incorrect 'First when |incorrect bounds of string
|assigning function-call.all |when assigned from
|(of access String;) to an |dereference of fun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264
--- Comment #2 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Sep 18 10:51:43 2013
New Revision: 202694
URL: http://gcc.gnu.org/viewcvs?rev=202694&root=gcc&view=rev
Log:
PR ada/58264
* gcc-interface/trans.c (Attribute_to_gnu): Define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264
--- Comment #3 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Sep 18 10:55:36 2013
New Revision: 202695
URL: http://gcc.gnu.org/viewcvs?rev=202695&root=gcc&view=rev
Log:
PR ada/58264
* gcc-interface/trans.c (Attribute_to_gnu): Define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
-linux |
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
Summary|[4.9 regression] ICE in |[4.9 regression] ICE in
|calc_dfs_tree, at |calc_dfs_tree, at
|dominance.c:397 breaks Ada
||2011-08-16
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Eric Botcazou 2011-08-16
17:12:00 UTC ---
> Well, look at the PR -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
Bug #: 50237
Summary: [4.7 regression] comparison failure caused by
HAVE_INITFINI_ARRAY check
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #2 from Eric Botcazou 2011-08-30
13:50:28 UTC ---
> HAVE_INITFINI_ARRAY is supposed to check the binutils/glibc feature,
> independent of compiler.
AFAICS it doesn't, it compiles everything with the host compiler, which will
use in p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
--- Comment #6 from Eric Botcazou 2011-08-30
15:00:54 UTC ---
> How does stage 2 binutils fail the test?
It doesn't. Let me explain:
- during stage1, the check is made with the host compiler, i.e. the base
compiler, so the old binutils are u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
Eric Botcazou changed:
What|Removed |Added
Summary|[4.7 regression] comparison |[4.7 regression] bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
gcc dot|
|gnu.org |
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #4 from Eric Botcazou 2011-09-03
13:23:55 UTC ---
Looking into it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #7 from Eric Botcazou 2011-09-03
13:28:43 UTC ---
Created attachment 25182
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25182
Tentative fix
Untested as of this writing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
--- Comment #5 from Eric Botcazou 2011-09-03
14:32:01 UTC ---
> and we have a CTOR and not individual initializations because of Erics
> const-pool changes I believe.
No, we have the constructor with GCC 4.5 as well, my patch only makes it go
th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #9 from Eric Botcazou 2011-09-03
14:45:01 UTC ---
> Thanks, starting bootstrap in a minute .. .
>
> ... your patch + this (and some unrelated fixes for powerpc ADA bootstrap):
>
> Index: gcc/config/rs6000/rs6000.c
> ===
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
Eric Botcazou changed:
What|Removed |Added
Attachment #25182|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #12 from Eric Botcazou 2011-09-03
17:28:32 UTC ---
> bootstrapped with your amended change to rs6000.c
> ./gcc/xgcc -Bgcc ../tests/hello.c -o hc -fstack-check -save-temps
> -fverbose-asm
> -fdump-rtl-all
> ... shows that the stack c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #14 from Eric Botcazou 2011-09-04
13:02:15 UTC ---
> for a smaller frame ... and the asm looks sensible...
Great, thanks.
Defining STACK_CHECK_STATIC_BUILTIN to 1 for Darwin would be a separate thing.
In particular, you'd need to te
||2011-09-05
CC|ebotcazou at gcc dot|
|gnu.org |
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Summary|ICE in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50294
--- Comment #5 from Eric Botcazou 2011-09-06
09:14:28 UTC ---
> My idea with fixing the Ada issue would be to conditionally use a signed
> or unsigned (sizetype) domain type. Not sure if all of the middle-end
> copes well with ssizetype domains
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50294
--- Comment #7 from Eric Botcazou 2011-09-06
10:21:42 UTC ---
> And 32-bit for 32-bit targets? sizetype is 32bits there ...
No, 64-bit type are supported universally. Of course your mileage may vary for
array types indexed with a 64-bit type..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
--- Comment #6 from Eric Botcazou 2011-09-06
21:17:51 UTC ---
Author: ebotcazou
Date: Tue Sep 6 21:17:46 2011
New Revision: 178611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178611
Log:
PR middle-end/50266
* c-common.c (c_ful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
--- Comment #7 from Eric Botcazou 2011-09-06
21:23:57 UTC ---
Author: ebotcazou
Date: Tue Sep 6 21:23:53 2011
New Revision: 178613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178613
Log:
PR middle-end/50266
* c-common.c (c_ful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||2011-09-09
CC||ebotcazou at gcc dot
||gnu.org
Summary|gcc/configure fails on Mac |gcc/configure fails on Mac
|OS X Lion/Xcode 4.1 if |OS X Lion/Xcode 4.1 with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342
--- Comment #4 from Eric Botcazou 2011-09-09
18:09:00 UTC ---
> Other than only building ada triggers the bug.
Huh? How could Ada have something to do with the toplevel configure?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342
--- Comment #7 from Eric Botcazou 2011-09-09
18:56:19 UTC ---
> Is there an approved way of getting CFLAGS="-D_FORTIFY_SOURCE=0" into the
> configure process? (there isn't AFAICT a problem with the actual build). I've
> tried
>
> ../gcc-4.6.1/
||ebotcazou at gcc dot
||gnu.org
Host||i[345]86-*-*
Summary|[4.7 regression]|[4.7 regression] bootstrap
|i386-unknown-freebsd|comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #21 from Eric Botcazou 2011-09-14
06:48:01 UTC ---
> All callee saved registers should never changed after function call. Here fp
> has been changed is not because it is after a function call, it is because it
> is after the target of
||2011-09-16
CC||ebotcazou at gcc dot
||gnu.org
Summary|[4.7 Regression] acats |[4.7 Regression] ACATS
|tests FAIL: c460010 on |c460010 fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #24 from Eric Botcazou 2011-09-16
21:24:30 UTC ---
> It seems postreload.c should be changed to the following to avoid combining
>
> --- postreload.c(revision 178904)
> +++ postreload.c(working copy)
> @@ -1312,7 +1312,7 @@ r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50433
Eric Botcazou changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #16 from Eric Botcazou 2011-09-18
22:00:57 UTC ---
Author: ebotcazou
Date: Sun Sep 18 22:00:52 2011
New Revision: 178944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178944
Log:
PR target/50091
* config/rs6000/rs6000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #17 from Eric Botcazou 2011-09-18
22:02:01 UTC ---
Author: ebotcazou
Date: Sun Sep 18 22:01:56 2011
New Revision: 178945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178945
Log:
PR target/50091
* config/rs6000/rs6000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #18 from Eric Botcazou 2011-09-18
22:02:31 UTC ---
Author: ebotcazou
Date: Sun Sep 18 22:02:27 2011
New Revision: 178946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178946
Log:
PR target/50091
* config/rs6000/rs6000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50433
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #2 from Eric Botcazou 2011-09-23
11:59:56 UTC ---
Investigating.
at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #11 from Eric Botcazou 2011-09-30
10:14:23 UTC ---
Investigating.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492
--- Comment #6 from Eric Botcazou 2011-10-07
11:43:08 UTC ---
Author: ebotcazou
Date: Fri Oct 7 11:43:03 2011
New Revision: 179652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179652
Log:
PR lto/50492
* gcc-interface/gigi.h (gn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50492
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #4 from Eric Botcazou 2011-10-11
09:48:05 UTC ---
It turns out that __builtin_offsetof goes through the new code. Fixing...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #9 from Eric Botcazou 2011-10-11
11:20:41 UTC ---
> It would be nice to know whether this particular FAIL is the failure
> of some checking mechanism or a genuine wrong-code bug. I suppose
> it's the former, and for -fstack-check we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965
--- Comment #12 from Eric Botcazou 2011-10-11
15:37:29 UTC ---
This is a fallout of the merge of the cond-optab branch in the 4.5 series.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965
--- Comment #14 from Eric Botcazou 2011-10-11
21:34:01 UTC ---
Author: ebotcazou
Date: Tue Oct 11 21:33:57 2011
New Revision: 179828
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179828
Log:
PR target/49965
* config/sparc/sparc.m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965
--- Comment #13 from Eric Botcazou 2011-10-11
21:33:28 UTC ---
Author: ebotcazou
Date: Tue Oct 11 21:33:24 2011
New Revision: 179827
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179827
Log:
PR target/49965
* config/sparc/sparc.m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965
--- Comment #15 from Eric Botcazou 2011-10-11
21:34:48 UTC ---
Author: ebotcazou
Date: Tue Oct 11 21:34:42 2011
New Revision: 179829
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179829
Log:
PR target/49965
* config/sparc/sparc.m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #23 from Eric Botcazou 2011-10-12
18:04:00 UTC ---
It turns out that Tom's patch is innocent, you can reproduce the problem at the
preceding revision if you compiled at -O1 instead of -O2.
This appears to be a problem in the signal u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #26 from Eric Botcazou 2011-10-12
20:55:31 UTC ---
> reproducible (using gdb 7.1) on darwin9 @ m64 (m32 is OK on D9 and D10) -
> - so where are we looking for a problem- in the m64 libgcc_s unwinder - or in
> the ada handers? .. or i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #28 from Eric Botcazou 2011-10-12
22:54:57 UTC ---
> OK. well libgcc_s or libSystem contains the unwinder, depending on whether
> it's darwin9 or darwin10 (and assuming that there's no insertion caused by a
> DYLD_LIBRARY_PATH). I'l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50589
--- Comment #1 from Eric Botcazou 2011-10-13
10:54:23 UTC ---
Author: ebotcazou
Date: Thu Oct 13 10:54:19 2011
New Revision: 179911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179911
Log:
PR ada/50589
* s-linux-alpha.ads: Do no
||ebotcazou at gcc dot
||gnu.org
Resolution||FIXED
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Target Milestone
||2011-10-13
CC||ebotcazou at gcc dot
||gnu.org
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
Ever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50354
--- Comment #2 from Eric Botcazou 2011-10-14
23:02:46 UTC ---
Author: ebotcazou
Date: Fri Oct 14 23:02:40 2011
New Revision: 180013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180013
Log:
PR target/50354
* config/sparc/linux64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50354
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||ebotcazou at gcc dot
||gnu.org
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #2 from Eric Botcazou 2011-10-14
23:58:50 UTC ---
Investigating.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||2011-10-15
CC||ebotcazou at gcc dot
||gnu.org
Component|middle-end |rtl-optimization
Ever Confirmed|0 |1
--- Comment #6 from Eric
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737
--- Comment #7 from Eric Botcazou 2011-10-15
14:56:44 UTC ---
> ... but looking at Dwarf2 frames dump, there is no "S" in any of the CIE
> augmentation data.
Try to add
fs->signal_frame = 1;
at the end of alpha_fallback_frame_state then.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #30 from Eric Botcazou 2011-10-15
20:49:03 UTC ---
> however I've not got far through Raise_From_Signal_Handler () - if one
> continues from there it ends with a loop on x86-64/darwin9 and another segv on
> x86-64/darwin10.
You need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #31 from Eric Botcazou 2011-10-15
21:34:32 UTC ---
There is some suspicious code in
#0 0x7fff85c75d48 in
libunwind::DwarfInstructions::stepWithDwarf(libunwind::LocalAddressSpace&,
unsigned long long, unsigned long long, libunwin
||ebotcazou at gcc dot
||gnu.org
AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot
|gnu.org |gnu.org
--- Comment #4 from Eric Botcazou 2011-10-16
11:25:03 UTC ---
Investigating.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50615
--- Comment #3 from Eric Botcazou 2011-10-16
13:14:37 UTC ---
Author: ebotcazou
Date: Sun Oct 16 13:14:34 2011
New Revision: 180058
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180058
Log:
PR rtl-optimization/50615
* combine.c (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50615
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50683
Eric Botcazou changed:
What|Removed |Added
CC||davem at davemloft dot net
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737
--- Comment #11 from Eric Botcazou 2011-10-16
19:33:19 UTC ---
(In reply to comment #10)
> Hm, I didn't notice new Java failure with the patch:
>
> === libjava tests ===
>
>
> Running target unix
> FAIL: Array_3 execution - source comp
601 - 700 of 5437 matches
Mail list logo
