Re: Bug detected as "a-comlin.adb:36:17 "
> please tell me about the bug or error.Now i am already > stuk i am unable to understand what to do next??? > so please help me!! Ada is not supported for this target. -- Eric Botcazou
Re: Problem building 3.4.3 on solaris 8
> I am trying to build gcc-3.4.3 on solaris 8. I get to the make install > point and then there is a problem. It appears the INSTALL variable is not > getting set right for the install step in the various directories. > > I have the source in /gcc-3.4.3 and the build dir is > /gcc-3.4.3_sun5.8 Use an absolute path to configure, not a relative one. See the Solaris-specific release notes -- Eric Botcazou
Re: Bug
> The attached code produces some garbage. With -O3 even worse. Attached > source and assembly file. How does that relate to the compiler? Could you precisely describe what you think goes wrong with the compiler here? -- Eric Botcazou
Re: signed enum bug
> The compiler outputs a bg branch instruction when it should use a bgu. The > cause seems to be related to having a negative value in the enumeration. Fixed in 3.4.4pre: _Z13DummyFunction10tTestEnum2: .LLFB2: !#PROLOGUE# 0 !#PROLOGUE# 1 add %o0, -2, %o0 cmp %o0, 1 bgu .LL2 mov 0, %g1 mov 2, %g1 .LL2: retl mov %g1, %o0 .LLFE2: .size _Z13DummyFunction10tTestEnum2, .-_Z13DummyFunction10tTestEnum2 .ident "GCC: (GNU) 3.4.4 20050224 (prerelease)" -- Eric Botcazou
Re: gcc-4.0.0 doesn't produce a valid assembler file
> gcc-4.0.0 doesn't produce a valid assembler file. > I didn't have this problems using gcc-3.4.2 > Info at end of letter. Posting to gcc-bugs is deprecated. Please file a bugzilla PR instead: http://gcc.gnu.org/bugzilla/ -- Eric Botcazou
Re: Native Linux Ada not Building on Trunk
> I am Fedora 9 (32 bit), svn trunk up to date as of a couple of hours > ago and the native build isn't working. Does anyone else see this? Yes, Ada has been broken everywhere yesterday, I'm going to follow up on [EMAIL PROTECTED] -- Eric Botcazou
Re: Increment/decrement operator bugs
> The result of an expression using pre-decrement or pre-increment such as: > y = x * n * --n; > gives different results in a few cases where x is placed before or after > the rest, or when its value is 1 or not. Please run the program attached > where a comment indicates what we think works wrong. We obtain: > > 1.- 16 > 2.- 16 > 3.- 16 > 4.- 40 > 5.- 20 > 6.- 16 > 7.- 40 > 8.- 32 > 1.- 36 > 2.- 36 > 3.- 36 > 4.- 60 > 5.- 30 > 6.- 36 > 7.- 60 > 8.- 72 > > In contrast, the results we get running it in a AIX Computer with the > native compiler (IBM XL C/C++ Enterprise Edition for AIX, V9.0 Version: > 09.00..) is what we expected: > > 1.- 20 > 2.- 20 > 3.- 20 > 4.- 40 > 5.- 20 > 6.- 20 > 7.- 40 > 8.- 40 > 1.- 30 > 2.- 30 > 3.- 30 > 4.- 60 > 5.- 30 > 6.- 30 > 7.- 60 > 8.- 60 As Andrew said, both behaviors are correct as per ISO C99 since the only constraint is §6.5.2.4: 2 The result of the postfix ++ operator is the value of the operand. After the result is obtained, the value of the operand is incremented. (That is, the value 1 of the appropriate type is added to it.) See the discussions of additive operators and compound assignment for information on constraints, types, and conversions and the effects of operations on pointers. The side effect of updating the stored value of the operand shall occur between the previous and the next sequence point. and there is no sequence point within the expression x * n * --n. As a rule of thumb, in C/C++ do not mention more than once in an expression a variable whose value can change as part of the "execution" of the expression. -- Eric Botcazou
Re: How GCC treats ice-on-invalid-code?
> It's fine to file these ice-on-invalid bugs, but don't be surprised if > nobody has time to work on bugs that are only triggered by unrealistic > garbage input. Right, an ICE is a perfectly valid outcome for garbage input and there are hundreds of assertions in the compiler precisely for this purpose. -- Eric Botcazou
Re: How GCC treats ice-on-invalid-code?
> You mean, an ICE is perfectly valid as the first (and obviously then > only) error diagnostic the compiler prints for “garbage input”? > If so, I don't think that's true. What counts as “garbage” seems > a bit too subjective for that anyway. When the input is totally nonsensical, e.g. generated by a machine for the sole purpose of torturing the compiler, an ICE is good enough and IMO the bug report should essentially be ignored. We have hundreds of open bug reports for perfectly sensible code and any of them should have higher priority. > E.g. deleting a chunk of lines from a file creates something that makes > no sense and might be considered garbage, but that can easily happen > with a botched resolution to a merge conflict (or being too trigger-happy > with git rerere :-)). I don't think it's OK for the compiler simply to > crash without first giving the user an idea of what's wrong. Sure, if the input originally comes from a real program, it's not garbage. -- Eric Botcazou
Re: bug: internal compiler error
> compiler failed in mid-compile of mysql source tree, -same-temps output > added as attachment We need the *.i file, not the *.s file. -- Eric Botcazou
Re: Optimisation Problem
> hello there... i am trying my hands on gcc optimisations options. > i tried e.g. -finline-functions, -funroll-loops and the likes but none > worked for me > for ex. i tried -funroll-loops for code > for (int i = 0; i < 3; ++i) > a[i] = i; Try -O -funroll-loops. -- Eric Botcazou
Re: Optimisation Problem
> But i wanted to try them indivisually. Is there any method to do so? The compiler doesn't optimize anything if you don't pass at least -O. -- Eric Botcazou
Re: Possibly a bug
> hello.c: In function ‘main’: > hello.c:13:1: internal compiler error: in calc_dfs_tree, at dominance.c:394 > Please submit a full bug report, > with preprocessed source if appropriate. > See <http://gcc.gnu.org/bugs.html> for instructions. This error means that some basic blocks are unreachable in the CFG. The CFG needs to be cleaned up before that point. -- Eric Botcazou
Re: build gcc (c,c++,ada) for ia64-hp-hpux11.23 fails
> If I skip the milp32 tree - the mlp64 tree works and I could produce > running 64bit binaries for my TARGET. > But because milp32 is default - cross compiling the native > ia64-hp-hpux11.23 gcc fails again. > > So my Question : > Does anyone know if I need some speciale configuration option for > ia64-hp-hpux11.23? > Or is there a problem with the ada EH_MECHANISM in the milp32 tree? > Or is there a posibility to build an mlp64 gcc only There is no full port of the Ada compiler to this platform in the FSF tree. You can only build a 64-bit Ada compiler with the unpatched sources. -- Eric Botcazou
Re: build gcc (c,c++,ada) for ia64-hp-hpux11.23 fails
> Do you know if there is any configuration option to force build 64bit only? Try --disable-multilib. -- Eric Botcazou
Re: 3-yr-old infloop in dwarf2out.c
> coverity pointed out the infinite loop below. > I guess it is unreachable or at least hard to reach, > or it would have been reported/fixed before now: Would you mind opening a PR with bugzilla? -- Eric Botcazou
Re: Create an so file
> I'm working on SOLARIS machine, and i have a problem. So on trying to > create the .so file with gcc command line, a fatal error was shown on the > screen. > > Command lines : > > gcc -c -I"/sw/java/j2sdk/v1.4.2/j2sdk1.4.2/include/" > > -I"/sw/java/j2sdk/v1.4.2/j2sdk1.4.2/include/solaris" -o GenExt2FS.o > > GenExt2FS.c gcc -o GenExt2FS.so -shared GenExt2FS.o -lgcc > > The attached file contain the output of the second command. Compile your source file with -fPIC. And you probably don't need -lgcc. -- Eric Botcazou
Re: gcc.4.1.1 compile error
> ./configure --prefix=/usr/local/gcc.4.1.1 --disable-multilib --disable-nls Never ever build GCC in the source directory. -- Eric Botcazou
Re: gcc.4.1.1 compile error
> The GCC is not build in the source directory. The source directory > is in another place (/usr/local/src/gcc.4.1.1). Then post the exact configure line. -- Eric Botcazou
Re: [Bug] problem with FP compliance using option -march=native
> Using compiler option -march=native create code that is not compliant with
> floating point standards for multiplication.
See the documentation of -ffp-contract=STYLE in the manual:
'-ffp-contract=STYLE'
'-ffp-contract=off' disables floating-point expression contraction.
'-ffp-contract=fast' enables floating-point expression contraction
such as forming of fused multiply-add operations if the target has
native support for them. '-ffp-contract=on' enables floating-point
expression contraction if allowed by the language standard. This
is implemented for C and C++, where it enables contraction within
one expression, but not across different statements.
The default is '-ffp-contract=off' for C in a standards compliant
mode ('-std=c11' or similar), '-ffp-contract=fast' otherwise.
--
Eric Botcazou
