--- Comment #2 from domob at gcc dot gnu dot org 2010-08-15 15:28 ---
Subject: Bug 45197
Author: domob
Date: Sun Aug 15 15:28:10 2010
New Revision: 163261
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163261
Log:
2010-08-15 Daniel Kraft
PR fortran/45197
* de
--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-15 16:21 ---
Subject: Bug 45211
Author: burnus
Date: Sun Aug 15 16:20:56 2010
New Revision: 163264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163264
Log:
2010-08-15 Tobias Burnus
PR fortran/45211
*
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-15 16:23 ---
FIXED on the trunk (4.6). Thanks for the bug report!
(I do not intent to backport the patch to the 4.4/4.5 branch; tell me if you
think it should be applied there as well.)
--
burnus at gcc dot gnu dot org change
--- Comment #3 from domob at gcc dot gnu dot org 2010-08-15 16:26 ---
Fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-15 16:26 ---
FIXED on the 4.6 trunk.
I have missed to include the PR when writing, submitting, and committing the
patch. It can be found at:
Patch: http://gcc.gnu.org/ml/fortran/2010-08/msg00174.html
Committal: http://gcc.gnu.or
--- Comment #4 from paul dot richard dot thomas at gmail dot com
2010-08-15 16:32 ---
Subject: Re: Segmentation fault with -fwhole-file for subref_array_pointer
Dear Jerry,
> --- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-08-09 17:18
> ---
> Paul, can you send m
The following program (pasted in the #fortran IRC channel) is accepted by
gfortran -- unless -std=f2008 is used.
Expected: By default a warning (or error) is printed - if two different values
are used. Maybe one should reject the program altogether - or allow it only
with -std=legacy. -- The progr
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-08-15
17:36 ---
These still appear to be present on i386-apple-darwin10 but not
x86_64-apple-darwin10. Odd.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45196
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-15 18:46 ---
A patch to do the parsing and some error checking has
been posted at
http://gcc.gnu.org/ml/fortran/2010-08/msg00181.html
It is not a complete implementation of the feature
and requires much additional work.
--
h
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:47 ---
Created an attachment (id=21480)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21480&action=view)
compressed preprocessed source for 20_util/auto_ptr/6.cc on
-i386-apple-darwin10
--
http://gcc.gn
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:48 ---
Created an attachment (id=21481)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21481&action=view)
compressed assembly file for 20_util/auto_ptr/6.cc on -i386-apple-darwin10
--
http://gcc.gnu.org/
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:48 ---
Created an attachment (id=21482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21482&action=view)
compressed object file for 20_util/auto_ptr/6.cc on -i386-apple-darwin10
--
http://gcc.gnu.org/bu
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-08-15
18:52 ---
Files created with...
/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/g++ -shared-libgcc
-B/sw_i386/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc -nostdinc++
-L/sw_i386/src/fink.build/gc
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target |middle-end
Ev
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-15 19:05 ---
Is this still a problem for you? I can try to help you here, but I need to know
what patch I should apply and to what revision, to reproduce the problem.
--
steven at gcc dot gnu dot org changed:
What
As originally reported at
http://lists.opensuse.org/opensuse-packaging/2010-08/msg00038.html POSIX 2008
says
(http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_12_03):
"2.12.3 Pointer Types
All function pointer types shall have the same representation as the type
poin
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-15 19:31 ---
> "*(void **)(&comp_compress) = dlsym(handle, "comp_compress");"
That is not alias safe. Try instead:
comp_compress = (__typeof__(comp_compress)) dlsym(handle, "comp_compress");
Which is alias safe. In fact readin
--- Comment #2 from artyom dot shinkaroff at gmail dot com 2010-08-15
19:35 ---
Created an attachment (id=21483)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21483&action=view)
Recent version of the patch for the revision 163240
Recent version of the patch for the revision 16324
--- Comment #3 from artyom dot shinkaroff at gmail dot com 2010-08-15
19:38 ---
Yes, I still would like to solve the problem.
I just uploaded the patch for the revision 163240 (2010-08-14). The bug is
still there. The problem happens when you compile the following code with "-On
-g".
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-15 19:38 ---
I don't think adding -std=posix is the right solution, since dlsym needs to be
usable if users choose other options such as -std=c++0x or -std=gnu99
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289
John Reid, The new features of Fortran 2008, chapter 5.5:
A pointer may be initially associated with a target:
type (entry), target :: bottom
type (entry), pointer :: top => bottom
*
Currently gfortran responds with:
type (entry), pointer :: top => bottom
1
E
--- Comment #6 from domob at gcc dot gnu dot org 2010-08-15 19:46 ---
Subject: Bug 38936
Author: domob
Date: Sun Aug 15 19:46:21 2010
New Revision: 163268
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163268
Log:
2010-08-15 Daniel Kraft
PR fortran/38936
* gf
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-15 19:47 ---
Yes, POSIX adds additional requirements about pointer representation and
conversion, but AFAIK all targets GCC support and have POSIXish runtime satisfy
that. The conversion between pointer types is not the problem in
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-15 20:01 ---
(In reply to comment #4)
> Possible solutions:
> 1) Make sure we use the right symbol from the right module.
> 2) Do the vtab initialization inside the module that defines the class, i.e.
> add a module procedure like
Opening caveats: This comes from a day of digging into why the Arduino
environment wasn't working correctly on my Fedora 13 system with avr-gcc-4.5.
I'm not a GCC hacker and not intending to become one, so forgive sloppy
terminology and if the right fix is one of the larger things I mention below,
--- Comment #4 from reddwarf at opensuse dot org 2010-08-15 20:21 ---
> Yes, POSIX adds additional requirements about pointer representation and
> conversion, but AFAIK all targets GCC support and have POSIXish runtime
> satisfy
> that. The conversion between pointer types is not the p
--- Comment #7 from domob at gcc dot gnu dot org 2010-08-15 20:25 ---
This extended the support to array-expressions -- the original example works
now. Next will be a rework to do the association in the trans phase, which is
probably necessary to get full array support and association t
--- Comment #1 from otaylor at redhat dot com 2010-08-15 20:27 ---
Created an attachment (id=21484)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21484&action=view)
Patch removing the frame pointer from general regs
Here's the patch described; I don't have any sort of extensive fr
--- Comment #7 from hjl dot tools at gmail dot com 2010-08-15 20:36 ---
It works for me:
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /export/home/hjl/bugs/gcc/pr45286/foo
Breakpoint 1, sigvtalarm (foo=0) at fo
--- Comment #8 from vapier at gentoo dot org 2010-08-15 20:40 ---
yes, we did. take the .i files we already posted and compile them with the
quoted pic/pie flags and look at the disassembled code.
the hardened gentoo variant builds all of glibc with pic/pie support (including
static li
--- Comment #6 from tkoenig at gcc dot gnu dot org 2010-08-15 20:41 ---
Hello Paul,
I think the patch you committed to 4.5 causes a regression for normal
loops, which are now handled as overlapping.
I think I fixed that in
http://gcc.gnu.org/viewcvs?view=revision&revision=162829
on t
--- Comment #9 from hjl dot tools at gmail dot com 2010-08-15 20:45 ---
You have to show me exact CFLAGS used to compile sigaction.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
--- Comment #4 from steven at gcc dot gnu dot org 2010-08-15 20:48 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #10 from vapier at gentoo dot org 2010-08-15 21:01 ---
from the glibc-2.11.2/signal/ subdir:
$ gcc -Wall -Winline -Wwrite-strings -Wstrict-prototypes -std=gnu99 -O2
-fgnu89-inline -fmerge-all-constants -fno-strict-aliasing -fno-unwind-tables -g
-pipe '-DWRAPPER_INCLUDE=' -I.
--- Comment #5 from matz at gcc dot gnu dot org 2010-08-15 21:07 ---
First, yes, the work-around from the official POSIX man-pages is alias-unsafe.
They added this example because ISO C doesn't allow conversion of void*
pointers to function pointer, but dlsym returns a void* pointer.
Th
--- Comment #11 from hjl dot tools at gmail dot com 2010-08-15 21:15
---
It works for me with -fPIC -fPIE using gcc 4.4.4 on
Fedora 13. I got
movq__restore...@gotpcrel(%rip), %rax
movq%rax, 56(%rsp)
in assembly output. It is correct. Please make sure that
you u
--- Comment #12 from zorry at ume dot nu 2010-08-15 21:31 ---
(In reply to comment #11)
> It works for me with -fPIC -fPIE using gcc 4.4.4 on
> Fedora 13. I got
>
> movq__restore...@gotpcrel(%rip), %rax
> movq%rax, 56(%rsp)
>
> in assembly output. It is correct.
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-15 21:33 ---
There are more possibilities, like:
3) void (*fnptr) (void); void *p = dlsym (...); memcpy (&fnptr, &p, sizeof
(p)); fnptr ();
The POSIX standard wording doesn't talk about void * and function pointers
being compatible
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-15 21:36
---
(In reply to comment #12)
> (In reply to comment #11)
> > It works for me with -fPIC -fPIE using gcc 4.4.4 on
> > Fedora 13. I got
> >
> > movq__restore...@gotpcrel(%rip), %rax
> > movq%rax
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-15 21:38 ---
Note that this is a common mistake anyways and for example with LTO we
unify all pointer alias-sets to that of void *. In fact I proposed that
for all languages anyway (look at the hack the C++ FE has for pointer-to
--- Comment #14 from vapier at gentoo dot org 2010-08-15 21:59 ---
we are using current GNU binutils (2.20.1). we dont use Linux binutils anymore
in Gentoo by default due to the instability and random patches that never get
mainlined into the GNU binutils. however, even with binutils-2
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-08-15 22:11
---
(In reply to comment #14)
> we are using current GNU binutils (2.20.1). we dont use Linux binutils
> anymore
> in Gentoo by default due to the instability and random patches that never get
> mainlined into the GN
When configured for i586-linux, there are extra
libgomp test failures:
FAIL: libgomp.c/nqueens-1.c execution test
FAIL: libgomp.c/pr39591-1.c execution test
FAIL: libgomp.c/pr39591-2.c execution test
FAIL: libgomp.c/sort-1.c execution test
FAIL: libgomp.c/task-2.c execution test
FAIL: libgomp.c/ta
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail||4.5.3 4.6.0
Known to work||4.4.4
--- Comment #1 from zsojka at seznam dot cz 2010-08-15 23:09 ---
Created an attachment (id=21485)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21485&action=view)
reduced testcase
Testcase crashes at x86_64-linux as well.
Valgrind output (r163261):
$ valgrind --trace-children=yes
--- Comment #2 from zsojka at seznam dot cz 2010-08-15 23:23 ---
Created an attachment (id=21486)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21486&action=view)
reduced testcase
Crashes at x86_64-linu as well.
Valgrind output (r163261):
$ valgrind --trace-children=yes -q
/mnt/sv
--- Comment #8 from matz at gcc dot gnu dot org 2010-08-16 00:55 ---
Well, okay, (3) indeed is valid ISO C (no warning) and works on POSIX 2008.
I'd find it very awkward to write such work-around for (1) just so the
warning in strict ISO C mode is silenced. I find this case different fr
with g++-4.5.1 (powerpc-apple-darwin8):
internal compiler error: in iterative_hash_template_arg, at cp/pt.c:1589
with the attached unreduced test case, which I'm delta-reducing at the
moment...
never tested against 4.5.0.
This code compiled with 4.4.x and earlier, which leads me to believe that
--- Comment #1 from fang at csl dot cornell dot edu 2010-08-16 01:07
---
Created an attachment (id=21487)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21487&action=view)
unreduced test case triggering ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45293
--- Comment #1 from hjl dot tools at gmail dot com 2010-08-16 01:13 ---
It is caused by revision 145825:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00448.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-16 01:18 ---
libgomp is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-16 02:29 ---
task.o is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
--- Comment #4 from hjl dot tools at gmail dot com 2010-08-16 02:52 ---
gomp_barrier_handle_tasks is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45292
This is a friendly reminder there's still no way to enjoy pextrw without undue
zero/sign extension unless inline asm is used; there's even a gradient of
ignominy from intrinsic to builtins, as exemplified by:
$ cat pextrw.cc
#include
long unsigned int foo1(__m128i x) { return _mm_extract_epi16(x,
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-16 05:04 ---
Disable
+(define_expand "cmpcc"
+ [(set (reg:CC FLAGS_REG)
+(compare:CC (match_operand 0 "flags_reg_operand" "")
+(match_operand 1 "general_operand" "")))]
+ ""
+{
+ ix86_compare_op0 =
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-16 05:18 ---
-mtune=i586 miscompiled gomp_barrier_handle_tasks which
has a loop and calls:
static inline void gomp_mutex_lock (gomp_mutex_t *mutex)
{
if (!__sync_bool_compare_and_swap (mutex, 0, 1))
gomp_mutex_lock_slow (m
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-08-16 06:09
---
The problem resides in resolve_transfer. The checks are not performed because
the expression is wrapped in parenthesis and so the expression is of type
EXPR_OP, so resolve_transfer is just exited. The following
--- Comment #2 from fang at csl dot cornell dot edu 2010-08-16 06:11
---
still reducing...
command to reproduce (passed to multidelta):
#!/bin/sh
g++-fsf-4.5 -pipe -ansi -pedantic-errors -Wold-style-cast -Woverloaded-virtual
-W -Wextra -Wall -Wundef -Wshadow -Wno-unused-parameter -Wpo
http://gcc.gnu.org/onlinedocs/gfortran/SELECTED_005fCHAR_005fKIND.html
only mentions DEFAULT and ASCII, it should also include ISO_10646 and possibly
some example for it.
Possible example (requires an UTF-8 terminal):
use iso_fortran_env
implicit none
integer, parameter :: wc = selected_char_kin
#include
register long double F80 __asm__("st");
typedef void (*inst_t)(uint32_t *ip);
void exec_inst(uint32_t *ip) {
((inst_t) (uint64_t) ip[0])(ip);
}
int main() {
return 0;
}
At -O2 and above gcc generates:
register_long_double_ICE.c:3:1: warning: call-clobbered register used for
glob
60 matches
Mail list logo
