Problem 1558 - Error 1540-0207 with IBM XL compiler in G4CascadeFinalStateAlgorithm.cc
Summary: Error 1540-0207 with IBM XL compiler in G4CascadeFinalStateAlgorithm.cc
Status: RESOLVED FIXED
Alias: None
Product: Geant4
Classification: Unclassified
Component: processes/hadronic/models/cascade (show other problems)
Version: 10.0
Hardware: Other Other
: P5 minor
Assignee: Michael Kelsey
URL:
Depends on:
Blocks:
 
Reported: 2014-01-08 00:16 CET by Tom LeCompte
Modified: 2014-06-28 01:04 CEST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this problem.
Description Tom LeCompte 2014-01-08 00:16:55 CET 
Using the IBM XL compiler (which I know is unsupported) I get the following error in source/processes/hadronic/models/cascade/cascade/src/G4CascadeFinalStateAlgorithm.cc, lines 152 and 153: 
1540-0207 (S) No common type found for operands with type "const G4String" and "const char [1]"


  if (GetVerboseLevel()>1) {
    G4cout << " " << (momDist?momDist->GetName():"") << " "
         << (angDist?angDist->GetName():"") << G4endl;
  }


This appears to be because G4cout is asked to stream either a string or
a G4String, and it won't know until runtime which it is.  This can be
fixed by forcing it to always be a G4String, i.e.


  if (GetVerboseLevel()>1) {
    G4cout << " " << (momDist?momDist->GetName():G4String("")) << " "
         << (angDist?angDist->GetName():G4String("")) << G4endl;
  }


The same problem occurs in  /source/processes/phonon/src/G4LatticeManager.cc
in lines 200, 207, 220 and 226.

The above fix compiles OK on both IBM XL and GCC.
Comment 1 Michael Kelsey 2014-01-08 04:21:55 CET 
Thank you for the note!  Since G4String is "just" a std::string, can you tell me if the XL compiler also complains about the following?

   std::string hw("Hello, World");
   std::cout << (5>3?hw:"Goodbye, World") << std::endl;

In principle, this should cause the same error which you reported.  I'm curious whether XL treats "direct" STL stuff differently from subclasses.

As for the reported issue, I can fix your problem by replacing "GetName()" with "GetName().c_str()".  That avoids creating temporary G4Strings, which are a non-trivial performance hit.
Comment 2 Tom LeCompte 2014-01-08 14:20:02 CET 
Hi Michael-

The XL compiler was happy with that code fragment.  

Cheers,

Tom
Comment 3 Michael Kelsey 2014-06-28 01:04:18 CEST 
This has finally been fixed.  Unfortunately, the fix didn't get into the 10.1-beta; my apologies.